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MEMORANDUM FOR: SEE DISTRIBUTION 

SUBJECT: DOD Electronic Commerce Requirements, Systems, and Implementation Strategy 
Version 1.4 


This document marks a milestone in the evolution of Electronic Commerce (EC). As we 
have struggled with understanding the requirements we have found that there are many 
systems and business processes involved in EC. Consequently, there are many differing 
strategies that need to be understood and made compatible and complementary. Version 1 .4 
of this document Is the first step in documenting a baseline and in developing a consistent 
strategy to benefit all the stakeholders. 

This document is the product of many people working together as a team to understand 
and confront the issues concerning the implementation of an EC infrastructure. It will be the 
document used, in conjunction with the Electronic Commerce Directive, to manage the evolving 
capabilities and opportunities that surface as we endeavor to make our government more 
efficient In this era of scarce resources. 



Deputy Under Secretary of Defense 
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1.0 EXECUTIVE SUMMARY 


nS Snn E o lS the - paper es T - s ^change of business information or ideas using Electronic 

Data Interchange (EDI), Electronic mail (E-Mail), electronic bulletin boards, Electronic^ SSfe 
(EFT), and other similar technologies. EDI, a primary method of conducting EC fctte * 

computer-to-computer exchange of business transaction information in a public format 

The federal vision of EC is a result of the President's direction that the implemen tati on of eiertrrmtV 
commerce be accelerated across the Executive Branch of the Federal Eminent The DOD fSS? s 
EC is to develop an electronic environment, supported by a standard architecture for electron^ ° f 
commerce that enables execution of the national military strategy during p e a c etime through 
mobilization, and warfighting sustainment. This 

throughout the business processes of the Federal Government. S gratmg EC 

The purpose of the DOD Electronic Commerce (EC) Requirements Systems and 
Strategydocument is to establish a common DOD EC vision £ EfflJ SfaSS ZTZ 
responsibilmes, and strategies for achieving a unified approach to EC implementation’imd operation In 
addition, it serves to document the current and future capabilities of the Defense Tnfnrmatinrf c„«* ' * n 
j? a ISA > “ *• ™? EC workload IZ&te 

y). Another is posting government requirements (business opportunities) on the WWW whirh 

^nn Z -n 0n *£ ^ ^ommercial electronic forms tecLb^ Sd provfdesT ’ 

person-io-machine interface for DOD contractors. w * p 

This document is a management tool to be used to describe the evolution of EC throughout the federal 
government. It identities existing functional and infrastructure capabilities issued 

SWSSSSif, E d 111 £ Federal g0Vernment ’ ^ depicts the vision^ 
fimtr m the D ? D J^ d civ ? ian a ? enc y perspectives. It delineates, at a high level the current and 
future requirements for EC implementations within DOD and civilian agenciel It chakcterizes L 
existing automated information systems (AISs) used bv DOD and the civilian acrenripc tu-t n a cr\r 
Sa - Cti °pr 11 de ! crioes ^ ^OD uiffastrucmre put in place to support both DOD and the civilian 2 

i ne information contained herein is available at multiple levels of detail from the hi*h level overview 

SSlCSSSSffi . - “I ™ 

!iSn e l e ! tS ' A ,< description of the functional requirements for the infrastructure that will support the 
mission. ~oals, and objectives of the business communities that are or anticipate using EC. ?? 

in place t0 suppon "» EC ^ *« 
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Strategy. The result of the analysis or requirements and system baselines that identifies considerations 
and recommended actions necessaiy to transition functional processes, systems, aDplic'ations. and 
deliver mechanisms to an EC environment that better supports changing missions' <?oais and 
objectives. ° 

In order to be effective, the overall strategy must address issues such as roles and responsibilities the 
£ e fS d j° f d ™ ntI01 EC “P^^ns, priorities, funding, schedules, cooperative 

^St^ffi?femrn^r ^ ° f partlCipantS m ^ P* 0 ^ must w °rk together to make it work in the 

The evolution of this document and the underlying strategy it represents depends, to a very significant 
extent, on the contmumg inputs from all functional proponents of the Federal govemmenuhat 
participate in EC. In addition to requirements, system baselines and strategies, the input of references to 
existing program and documents (such as reports of working groups andtction teaiAs) will S5 
enhance the effectiveness of this document. These inputs should identify the references and if 7 
applicable, indicate available methods to access them, such as a WWW Uniform Resource Locator 
CURL) or an Internet File Transfer Protocol {FTP) address. They will be incorporated into Appendix Y 
of this document and be made available to the Federal co mmuni ty " 
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2.0 OVERVIEW 


2.1 Purpose 

The purpose of this document is to establish a common DOD EC vi<5inn hv 

« P T ,biliti “’ “ d ““** - "*S* approach to 

It is designed to: 

• Provide consolidated information on all DOD EC initiatives for use bv C u^m,.« «■ 

program managers, policy makers and commanders by rS ’ actl0n officers ’ 

• Define the roles, responsibilities and relationships of participants inEC and Fnr 

• Identify the core components of the DOD EC inLstrKe 01 

Document migration and implementation paths for EC and EDI 

' the" Fedc^&vcZ™ “ d ™ erde P endradcs ° f E C and EDI efforts across the DOD and within 

• aCr0SS "» D0D » 

duplication of efforts S P me UtlIl2aUori of ^signed resources and preclude 

• Describe initiatives to eliminate impediments to the renlimrinn r\fv:r • i 

■ inithth^ re< ^ uiremenls an d management of core DOD EC inlrastmcru^^components. and 

^ Bh fs l rf ,,id ““ EC '&>» 

suppon the Draft Directive and carrv out its reauirempnr*’ i > m ° re detai ’ how D. 0D organizations will 
the Military Services, Defense Agencies OSD^Princinal Staff' P res . e nts a consolidated EC framework for 

cotnmnnit.es, and will be n^d Son I Sir Si Sf plgSS ? Clr 
representative of the DOD Execimvp Arrant fm- n n ^ nnci P a ^ Staff Assistant for EC, and 

Secretary of Defense (Acquisition Refonn) [DU'S DIARiTwi n , ^' SDA&T ^' the De P ut y Under 

Director. DOD Electronic Comma™ the joint efforts of the 

.Analysis (DIS.A-D7) in the eSon of this si^| ’’ “ d ^ DepUty D,rec,or - Join ' Requirements & 

2.2 Background 

Exhioit 2.1 summarizes the maior events in the evolution of FC anH pm ;n *i,_ p j i 
the early 1960s. the DOD developed the Military Standards /vmS? EDI th J fedemI government. In 
the EDI technologies that we emplov wdavfothe earIv^970^he T^ Stem ^ en ^ b y ? e P recursor «> 
Committee (TDCC) bezan the development of aWFnr Jan^ Trans P ortauo ? Daa Coordinating 
length records and be flexible to suppS^ variable 

from the private sector, the Americ^ P , nmarily 

1 979 as the US national standard for EDI. 1 1A.NM) X12 standard emerged m 
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Exhibit 2.1 - Evolution of EC and EDI in the DOD 

For many years the DOD has advocated the use of EDI technology to improve its operations' and the 

PT ded t0 ltS C r°T S * A 1988 DepUty Secretar y of 5 Defense memo, addressed to “e mihtarv 
services and agencies, solicited maximum use of EDI, based on ten years of DOD EDI experiences. 

In July 1993, the Deputy Under Secretary of Defense (Acquisition Reform) chartered the Electronic 
Commerce In Contracting (ECIC) Process Action Team (PAT) to conduct a bottom-up review of 
existing and ongoing use of EDI technologies in Defense procurement systems. The ECIC PAT with 
representatives from across the DOD and advisors from Federal agencies and the private sector 
developed an implementation plan for an integrated DOD-wide approach to ECIC. 


In September 1993, the National Performance Review recommended that EC and EDI be expanded 
within the federal acquisition system. p a 

In October 199 j. President Clinton signed an Executive Memorandum directing the broad and rapid 
implementation ot EC to support a full scale Federal EC system that expands initial capabilities to 
include electronic payments, document interchange, and Federal purchases. 

The Congress, recognizing the potential for savings and process improvement in the Federal 
government, based on the experiences of the private sector and limited governmental use, required the 

S^eSmltirin^Tctof 199 EC ^ ^ certam P rocureme nt actions in the Federal Acquisition 

Because international trade is becoming increasingly common, the ANSI XI 2 Standards Committee has 

Tran^nnnN^’^nf^Ar'n^ 1 ” 1 ^ 6 ^ widl Nations EDI for Administration. Commerce and 

rransoortlDN^DIFACT) standards to ensure interoperability. This alignment will begin in 1997 and 
will lead to the achievement ot a single global EDI standard. 
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2«3 Organization of the Strategy Document 

This document is organized into five main sections and a series of appendices.' ' 

The Executive Summary provides a high level overview of the document, stressine the main 

££££ “ ponant 1SSU “ identified ““ major c “ dusions “ d SSSritoa, 

The Overview section discusses the purpose, background, and vision for EC within th<» p»ri i 

eVOlUd ° n ° f 1116 d0C “ n “ t ’ “ d * 

EDI implementarions/lncludes^discu^on^f^he Safe 1 ” 11 throughout most 

and indudes refemnces to specific fimctionai requi 

ScStt 

support both the generic requirements and specific DOD and Civilian AgendelifEC 
implementations, resource priorities and funding issues. P d establish 311(1 support 

&*** or r ati - «■“ - 

This wiii facilitate the capability of DBA™ 

2.4 Electronic Commerce in Contracting Vision 

dobument^e^the 0 ^^ stnve^o* ^et Aa^vision Th^foli* 

assumptions, principles, goals and objectives will allow the fulfillment of this vision. ° Win§ 

Exhibit 2.2 depicts the constantly evolving flow of transactions that renresent the nntenr.^l 
interoperability between Federal, State, and Local infrastructures and pr^lsLs ? 
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Exhibit 2.2 - EC Vision 


2.4.1 Assumptions 

As shown in Exhibit 2.3 the evolving EC infrastructure will support the flow of these transactions via a 
variety of paths. The following assumptions must guide the DOD EC Infrastructure and the use of it bv 
"l^imna! communities. Because the DOD Nonclassified Internet Protocol Router Network 
(NIPRNET) and Internet are interconnected, the Services and Agencies will have options to- 
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Exhibit 2.3 - Evolving EC Infrastructure 


Traverse the NIPRNET and make use of the Electronic Commerce Processing Node (ECPNT nr 
the Defense Automated Addressing Svstems Center ('DAASC'i rn fnn.vnrH „„ki' (tLrN) or 
DOD certified Value Added Network (VANs) Q fonrard public P roc ' Jre i"nts to 

* Traverse the NIPRNET and make use of the ECPN or the DAASC to forward directed 

procurements to DOD certified V.ANs orwara directed 

* ^o^gT^ImeS^ 7 311(1 dirSCted pr0CUrements directl y t0 DOD certified VANS 

- vl e fa DISN/FTS2000 and pass transactions directly to DOD certified 

* Internet buUetm boards with V/ " EB servers 11121 ^ accessible through the NIPRNET and the 
2.4.2 Principles 

The principles of the DOD EC and EDI program are to the maximum extent practicable: 

* Utilize EC/EDI to enable business process reengineering. EC practices that impede business 
process reengineering or improvement should i^unediafelv be brought to AeXntion c of rhe EC 
Executive Agent, who shall take immediate action to resolve anv such issue 

w Adopt no technicd solution that will prevent utilization of new technologv to accomplish EC/EDr 

* Sm^c face to industry” (one time entry into a system bv a vendor) when so^a DI 

. Use^he cnSJf?? 8 COn !f 2c:or reglstnmo ^ receiving cenifications and representations * 

Lse the same data, without reentry, m all functional areas (e.g. Contracting Financial 
Transportation. Medical) v »’ '- ontracu ng, financial. 

Require no organization to transition to an EC architecmre that does not meet or exc-ed the 

. S! S AV?? ! vW S / S,em being utiIi2cd b ? that organiLtl " “ Md ‘ he 

EDIF ACT standard " f ° r transactin i business, migrating in the future to the UN 

2.4.3 Goals 
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The goals of the DOD EC and EDI program are to: 

' * ““ CUnOTt ““ B * take 

• Establish a Centralized Contractor Registration (CCR) capability to do business electronicaliv 

5 standardized Federal EIe «0"i<= Commerce Acquisition 

• ™SniScraM° d of implementing the national (ANSI X12) and international 
Sfcmattan"fl^ ED Ca0n fotmats t0 enable un P rov ' d external and cross-functional 

• Modify existing legacy systems to be EC and EDI capable. 

• Establish an Electronic Commerce Information Center (ECIC) 

• Use the Acquisition Reform Communications Center (ARCC) for education and outreach 

• SS SKT ^ CEFT) architeciure and use l^e'^cipal 

• Allow Federal contractors not using EDI to benefit from EC by accessing oovemment 
requirements (business opportunities) through the World Wide Web (WWW). 

2.4.4 Objectives 

The objectives of the EC and EDI progr am are to: 

• te° Ve t fficienCy “£ [ow f T costs by simplifying and standardizing procedures for processing 

• oSgS” enibTe BPR S ” KnSiVe manUal aCtions 

• Juch U S pa^fer^e^e^^l^don'cmd^miii^s^pHe^ "“ g nKd f ° r COS,ly " s 

• Reduce labor costs by decreasing the amount of manual processing required to do business 
Increase reliability or transaction data by reducing manual input and human interpretation of data 

• Reduce time required to prepare, process and transmit a business trar^Sn ^ 

• Reduce costs by decreasmg required inventory levels due to shorter acquisition lead-time 

• bidd - ^ public 

• Provide more comprehensive transaction history and status information for management decision 
. makers by proving au.oma.ed audit mails for events such as daytime 

• Eliminate duplication of effort and resources bv migrating to a centrnlfrprl infnctmrr.n.a u* u 

SfflS SyLfmTDMt S SyStemS Nttwwk . < DISN > 

• fonmwtore 1 * CUrrent Federd ' wide manUal ^ du P licative registration process for government 

• Provide a one-stop information resource for Government EC information 

• Federal ^ instirutI0nall2ed ca P abiIity **> « d ^ate and train the work force and trading partners on 

• Provide an interoperable electronic environment that reuses shareable data across functional areas 

common ttlecSmm^^oL biK“To^mpUd 1 E *i^' C ° mm ° n transacuon data standards and a 

• Pf- CCR P rovid £ a central repository of information on vendors necessarv to conduct 

• VVI -n ther 2‘ The , inl0 ( matl0n vv iH be available throughout the Federal Government 

- - fV a \'c?Lh>L need 5 SUDS , caoe t0 onl - v one of the many DOD-cenitied Value Added Networks 
^ cb pr ° vide 5 adin g parmer connectivity to the infrastructure 

• The DISA Compliance Test Facility (CTF) will perform certification of a trading partner's 
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capability to comply with Federal Government EDI implementation conventions. 

2o Definitions 

There are many similar, yet differing, definitions of EDI and EC heina hc»h 

feoods «*«> ° r 

EleconiAuads Transfer 

computer-computer exchange of business transaction 


example, E-Mail can be created on-faXSl^tS,"/ P a P cr d °cum«tta. For 
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These are stnct definitions in the sense that. EG is. ’paperless’ and EDI is bound to a-'pub lie standard ’ Of 
course, while there exist a number of instances where information is exchanged electronically much of 
this data exchange is done using proprietary formats that are not generally available to the public. This 
strategy for EC and EDI within DOD focuses on the migration toward using the American National 
Sumtods Institute (ANSI) Accredited Standards Comndttee (ASC) X12 EDI san££f“aU Kess 
transaction interfaces which analysis indicates benefit can be derived, both internally within DOD and 
externally with other governmental agencies as well as the commercial sector. The strategy also ’ 
recognizes that the international standard UN/EDIF ACT is used by some Federal agencies and the U S 
X12 , sta f dard IS expected to be aligned with it in the relatively near future. DOD will support the ’ ' 
s^d^d appropriate to the using activities that it is supporting. In the remainder of this document the 
term XI 2 will be used to imply whatever standard is appropriate for the implementation. 

The following definitions are the foundation for the basic understanding of EDI concepts. 

Trading Partners- Entities who exchange business transactions. 

Government entity with whom the FedemI Government 

SfS £%£ £ endt^ G0V “ ^ Wh ° eXChan8M teilKSS 

Xr ansaction Set - A semantically meaningful unit of transaction information exchanged between EDI 
trading partners. It can be thought of as the electronic counterpart of a paper document that represents a 
transaction, e.g., an invoice, a bill of lading, or a medical insurance statement. 

Xransaction - All of the business information contained in a transaction set. 

S SS nSaCti ° n ^ ^ ansactl0n ^ , rather ton bei ng sent to one trading partner, is broadcasted to a 
ZZiTZk™* ? ftn i dmg pa ^ ei i s - Alte matively, a transaction that is made available to anv trading 
partner by being placed in a publicly accessible media, such as an electronic bulletin board for 
downloading. ’ 

Im plementation Convention - A subset of the X12 standard that represents the common practices and/or 
interpretations of the use of X|2 standards. Conventions define how tradina partners will use the 
standards to accommodate their mutual needs. 

POP EC and EDI Infrastructure - A subset of the DII that is designed to suDDort EC and EDI It is 
composed of hardware, software and people. It provides services'" such as translation archiving 
distribution, and result notification. It supports all DOD EC and EDI functional activities as well as 
other civilian agencies that may need to use it. 

FAC^EJ- Federal Acquisition Network was created by Section 9001. Federal acauisition Streamlining 

Electron?c Cn PUb ’ L ‘ rp!" 355 ’ 9 C J: 13, 1994, 41 USC426. FACNET is defined as: the Government wide 
Electronic Commerce/EIectromc Data Interchange (EC/EDI) systems architecture for the acquisition of 

supplies and services that provides for e ectromc data interchange of acquisition information between the 
Government and the private sector, employs nationally and intemationallv recognized data formats and 
provides universal user access. FAR 4.501 ' • 1U 

Interim FACNET means a contracting office has been certified as having implemented a capability to 
provide widespread public notice of, issue solicitations, and receive responses to solicitations and 
associated requests for information through FACNET. Such capability must allow the private sector to 
: ™ ll . ces 01 soll citations. access and review solicitations, and respond to solicitations 

a" 01 a SI?CC x C but nther 1 SerieS ofcapabilities. For procurements at or below the 

Simplmed Acquisition Treshold, a contracting activity using an Interim FACNET certified svstem is 
exempted from the requirement of posting or synopsis in the Commerce Business Dailv (CBD) as 
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soUciation ! ^ ^ ^ (13) ** WaitlnS Peri0dS required before award or issuance of the 

Exhibit 2.5 identifies some of the EDI components in a cross-functional imDlementation nf Fnr 
represents a conceptutU example of the vision for EDI in DOD. This example integrates the oroc^Lnt 
and finance fimcnons by passtng XI 2 transactions among the various eSS comnonenTS 

5 , eXte T I “? mlercial “ ddes “ vol '' sd “ <*' P^ess of acqu^gS^d ^ri«s -Hi? 
example shows the entire process beginning with a reauisition and pnHinrr ♦ s. ine 

“SaS“ r - 111 “* ■"»"* authen.icSetu'Se? 


ED! 


G o vernm ent A ctivity 
with a Requirem ent 

m 


Contracting Office 
(Internal Trading Partnei 



( 8 * 0 ) 

Pnac^oi » Oalas (35 0 ) 
PrymiarOBiii/ 
laairf4A£a Mvic» (320) 


Finance 

(Internal Trading Partner) 


B an I 

(External Trading 
P artner) 

Exhibit 2.5 - EDI Example 


VENDOR 
(External Trading 
Partner) 


2.6 Document Evolution 

vS?nc 2 v providesa Wsh. level description of this document and the anticmated content for following 
^^rsioris. version 1.0 contains the near-term strategy Version 9 n \xriii nrmtom t-u ^ 
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Exhibit 2.6 -DOD EC and EDI Strategy Timeline 
The version dates and contents are described below: 


17 October 1996- V 1 . 0 

Appendices will include the detailed EDI Baseline, and Strategy documents for DLA Finance and 
Accounting, Transportation, DOD Small Procurement, Medical Logistics and the Federal 
Agencies as provided by the functional community. 


• 3 1 April 1997 -V 2.0 

^ 0 S'raKaiS m0re d ' ,aiI f ° r DLA ' ° FAS “ d Trans P° rati °°- additional functional areas. 


• 30 October 1997 -V 3.0 

Imormation from V2.0 plus more details and additional functional areas with strategies 
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3.0 REQUIREMENTS 


Tnis section identifies the infrastructure characteristics that are normally required in an EC and EDI 
implementation and describes elements which need to be elaborated during program or profit h 
definition. It ^introduces : a process which can be used to ensure the business requirements are identified 
recorded, and saosfied.It refers the reader to documents of specific EC and EDI projects for which 
requirements are known or being developed. v J mcn 

The existing Defense Information Infrastructure (DII) satisfies many of the requirements for moving 
electronic transactions^ between tradmg partners. There are, however, specific required features that are 
not currently identified or supported by DU. This document encourages the contribution of information 
from readers to assist in the identificauon of additional features required to conduct EC. 


3.1 EC and EDI Infrastructure Requirements 


Srrrfp 1 re ^ ulr . em . ents _ for aid EDI are derived from the DOD Electronic Commerce in Contracting 

311(1 the Federal Streamlining Acquisition through Electronic 
iriSa^cmre AT R p0rtS ' ^ foUowm g basic requirements apply to the Federal EC and EDI support 

The ^ astrucrure T* beca P able of supporting the following functions required to 
process and transmit transactions electronically: 4 

• Translation of user defined files into X12 transactions and decode X12 transactions 

' “ d fi " B " Ss - cenifted Vdue Added 

’ BSSyZlf 15 ° r C0mpanies acting “ their 0wn VANS “ d with a 

• Providing directory services required to route transactions 

• Validation of trading partner information 

• Compliance testing 

• Acknowledgment of unsuccessful processing 

• Archiving of data 

• Provide for accounting and billingservices 

• Provide for query and trouble reporting capability 

Central Contractor Registration- The infrastructure must provide a fullv operational capability for 

"Ssr” d ° bUSineSS dl ^-^depantnentro^F^era, 

» -lade total 

• problems 1 ' 1 ' 1 ' 3 * Strvdc5s re cuired 10 ensure data recoverability in case of hardware or software 

• Con, j nuir y? f Operations (CO9P) capability to reroute transaction workload durina 
standdown of an infrastructure processing node or communication channel. 

Security - The infrastructure must provide security services that will: 

• ^?//r^ dUreS - and mec u hanism I !i 0 ensure security equal to or greater than that currently 
afforded to transactions m the non-EC environment. This includes maintaining the integrity' of the 
data contained within the transaction as well as safeguarding the data against disclosure to' 

* • no^anmvid^f ' A rlfT"* de !S U °?*- ° r addition of “y of the~original transaction should 

not be allowed, but must be detectable if it occurs. 
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Provide procedures and mechanisms to protect infrastructure hardware, software, and data from 
tampering or unauthorized access. 

• Provide procedures and mechanisms to positively identify the transaction originator and recipient 
Misrepresentation ot the onginating/receiving party must be detectable. H 

Developmental T e . sting Support- The infrastructure must have the capacity to support the testing of new 
implementations and prototype developments while preventing interference with production opemtioS 

End-to-End Reliability - frifrasmicture users must be assured that their transactions will be delivered to 
the intended recipients. The infrastructure must mclude procedures and mechanisms for notifying users 
of undehverable transactions (e.g., unidentifiable address). ™ * ** 

Auditability - The infrastructure must provide a transaction audit trail which allows infrastructure 
operators to follow the status of a transaction as it traverses the infrastructure and to reconstruct the 
times of transaction events after a transaction has exited the infrastructure. 

Scalability - The infrastructure's architecture will be scaleable to facilitate rapid expansion in order to 
accommodate additional transaction workload. 

Use of Dll Components - The infrastructure must make maximum use of existing and emerrin^ 
components of the Defense Information Infrastructure. ° s 

Use of Off-The-Shelf Products • The infrastructure must make maximum use of 
Commercial-Otf-The-Shelf (COTS) software and reusable Govemment-Off-The-Shelf (GOTS) software 
products that have been tested, accepted, and are configurable and/or supportable by the GoST 

Data Conventions- The infrastructure will only transmit Federal Government-approved implementation 

conventions which are based on X12 and/or EDIF ACT standards. mpiementanon 

3.2 Requirements Identification Process 

J?nS^ e - VOrk f0r Dri ri?c e p tion ’ shown in exhibit isa methodology for handling a wide variety 
of DIS A requirements. DIS As customer (Or "user") organizations generate the majority” of DIS A 

program requirements The DII receives and implements these requirements. The Requirements Process 
and its supporting tools structure is the mechanism by which user needs are integrated into DII 
programs. 
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Exhibit 3.1 - Framework for DII Integration 

R!c*t requirements are typically identified by three sources: (1) DISA D7 Integration Managers* P) 
DIbA Customer Representatives assigned to DISA Directorates other than DISA D7- and (3) 
Cross-Functional Requirements resulting from maturation ofthe System Interface/Data 
Exchange(SiyDE) and the identification of Base Level Interfaces to CINC/Service and Global Command 
and Control System (GCCS)/Globai Combat Support System (GCSS) programs. The process tracks the 
evaluation, documentation, and disposition of requirements identified by the three sources. 

3.3 Requirements Process 


The general EC and EDI infrastructure characteristics described above will be analyzed in the context of 
DIbA's current and future capability to meet specific requirements of the Federal user community The 
user requirements collected are presented in the appendices to this document. As pan of document 
evolution additional requirements will be collected and the appendices will be updated. 

Section 4.1 focuses on the current DOD EC and EDI infrastructure, maintained bv DISA, with the intent 
to baseline the infrastructure’s functional and technical suppon capacity. Based on that capacitv versus 
the reqmred capacity, the implementation strategy will be developed. Issues and recommended actions 
will also be developed and maintained in Appendix X. They will be organized in a manner that permits 
tracking the actions. ~ * 

3.4 Specific Project Requirements 

The purpose of this paragraph is to provide references to specific EC and EDI projects for which 
requirements are known or being developed.For each project mentioned here, there will be an appendix 
containing a short summary of the project. The reader can use that and the referenced requirements 
document to understand the full scope of the project. The reason for this format is to provide a 
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consolidated summary of requirements while avoiding duplication of the details nf -mv 
app“^aKa“penfc ** ^ be b ? D'SA and inti the 


It should be emphasized that this document is the result of the contributions of the entire DOD and 
Federal community and comments and suggestions are welcomed from all. This is especially true of the 
appendices, which should describe the EDI initiatives from the viewpoint of the °f the 

Staff Assistant (PSA), military service/agency or federal Sen^y ^ respective Pnncipal 


3.4.1 DOD DUSD(AR/EC) 


Use of EC/EDI to support DOD procurement processes for amounts of S25K to S100K ha* heen 
consideration for some time. The Deputy Under Secretary of Defense fAcaSsiti^ 
a Process Action Teain (PAT) to assess current contracting capabilities in die DOD EC anH Fn? ^ 
mfrastructure. The PAT was tasked to develop a comprehensive plan for implement's £ EC a * 
for procurement functions that was consistent with X12 standards inte^™d DODS^ 
greatest capability within 2 years and identified relevant policy issues provided the 


In line with the PAT report, DOD identified the organizations that partici pate in the n rnmram- L.. i 
process, determined the types and quantities of business tr ansac tions exchanged and^ormulateH a nii 
o, grate the^traasactiojs to the new standard XI2. At th^e toe“ P 

common infrastructure for moving these procurement transactions is able to handle the predicted 
£“d£ “c C £*nt P0SWVe COnflmati0n ° f « Iore 


3.4.2 DOD Finance and Accounting - Unmatched Disbursements 


the sj^^a^e'De^we ^c^^ing anTph^ce^^^M^DF^AS^is currendv to improve 

finalized recommendations, the EDI portion of which is to be supported bv the *El?I P po nfon^ f the 2 D II 
The requirements that have been developed are being documented in a Dt'sa rJwt P n??? ?/• . 

de£Z C d ed Disburse ™ nts ' F™«ional Requirements Document , sponsored bvDISA-Dl. A more 
detailed summary of this project can be found in Appendix B to this document” 


3.4.3 DOD Transportation 


Transportation Electronic Data Interchange Implementation Plan. 4 June 1996. 

transportation l¥?nHn ? r0 ? rai ^ t0 ^ ccsI< : rate the pace of EDI implementation in support of 
usTs fn ^ mmed at ener - v ' mention and resources toward expandin- EDI 

uses in support of DOD transportation business information exchanges It identifies basic rennfrement. 
.or the use of EDI in support of DOD transportation in addition to ditaiiin» die c toEI a 
more detailed summary of this program nan be found in Appendix C to S A 


3.4.4 DOD Medical Logistics 


Medical logistics is a function within the Military Health Services Svstem (MHSS) a worldwide 
orgamzation composed of the health resources of DOD, Armv Navv and Air Fore- The infnrmnh'nn 
required for MHSS covers a diverse range of peacetime’ and wa P-Se^eS 

managed care, preventive medicine, research, and logistics. Medical logistics suooorisfoe he^Sh 

care delivery mission bv furnishing materiel, equipment facilities, s£ ? cTanSoma£ Sol«s 
essential to patient care in both peacetime and wartime. 


The Defense Medical Logistics Standard Support (DMLSS) Pro-ram is resoonsible for ^ 

ncdical l0S l S,ics su PP° n environment for health^ £ra^ in pe “mime 
ilitary operauons other than war, and wartime. The program is composed of tw 0 P major components: ’ 
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SffiSS? entonce. and automate medical 


Wntefi3S£ app rT ° f “ 

IJt.- P '’ ^ luch ldentlf ^s and implements improvement opportunities associated with the business 

"*■ deniled ™ ° f *»*££££Z be 


3.4.5 DOD Procurement 


The miUtary deportments, defease agencies, and their components have developed processes and 
business practices, including approximately 76 unique AISs, to perform their proci^mem Sons. 


The Director, Defense Procurement, recognizing the inefficiencies and cn-n-c _ • . 

SK&SS&2 X' SPIT' 1 * pr °' u ? m ‘? t sy^nia. established the Standard Pro^rement “ S 
ystem (orb) Program. The SPS Program is iterative and provides the capabilities and denlovmpnt 

hmes^phased to correspond with user needs and budgets. For EC/EDI purposes, the key elem« J of the 


provides the capabilities and deployment 

r? o m i \r • . . • 


software application that will perform standardized procurement functions 
effort, d pr0CUremeat ^ develo P ed conjunction with DOD Enterprise data standardization 

a shared data warehouse that will permit receipt and distribution of standardized procurement data. 


• and the DOD Defense Information Inffastructure(DII). 

A more detailed summary of this function’s programs can be found in Appendix E of this document. 


3.4.6 DOD Logistics 


3.4.7 DOD Agencies 


3.4.7.1 DLA • 


3. 4.7.2 E)eCA 


3.4.8 Military Services 


3.4.8.1 Army 


3. 4.8.2 Naw 


3.4.S.3 Air Force 


j’ eS c Alr tr ° rCe Elec:r ° nic Commerce/Electronic Dam Interchange Strateav. 12 Julv 199J 
desvnbes the Air Force vision, goals, and strategies for EC. The Air Force hai embraced EC as a wav to 
improve quality and reduce cost of operations well into the next centurv. The AkF^rc- has s^erd 

Scme™ y ' SUmmaty ° f lhKe Wtiatives Can 136 foun<i ' in A PP*ndix H of “S of 


3.4.S.4 Marine Corps 


3.4.9 Federal Civilian Agencies 


3.4.9.1 Federal Procurement 
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4.0 SYSTEMS BASELINE 


l of 9 


Tlie section provides a high level description of the EC and EDI infrastructure maintained by DIS A It is 
Fed^Gove^n^ 10 ^ ° f SySt6mS ’ ^ t0 What EC SUpP ° rt i$ availabIe t0 111 tie' 


.The first step in expandmg EC within the Federal Government is to determine the current use of the 
infrastructure in major functional areas. This assessment is used as a starting point for a continuing EC 

the war5ght« C * ent ‘° ^ i ” f0nnCd dedsio “ for ex I> m<fcd EC SU PP°" » 


Most of the current EDI support provided by DIS A is in small procurement, where there are already 
several military and civilian activities that are conducting business using the infrastructure in various 
degrees of volume. It is imperative that current and planned use of EDI by these organizations be 
documented so that adequate future support can be planned and provided. 


D . IS £ ^R r x^ de f 0t ^l T f ? su PP ort ' m tie form of World Wide Web (WWW) Home Pages, accessible 
via the DOD Nonclassified Internet Protocol Router Network(NIPRNET) and the Internet This surroort 
now includes information related to policy, direction and general topics. This strategy document b 
available m electronic format Appendix Y to this document lists many related reports and other 
documents and how to obtain them. Readers are encouraged to provide additional information regarding 
on-line documents. Other EC support mcludes the on-line trading partner registration capability berna * 
built into the Central Contractor Registration (CCR) system p y 3 


?n docume ° ted E( r 211(1 EDI baseline mdicates that more functional integration is needed in 

Snmi y , me the reqmrem ! nts / or D0D mission support and for the warfighting communities The 
lack of full integranon causes redundancies and duplications that increase the cost of operations, thereby 
reducing the resources available for the DOD warfighting mission. However, several EDI efforts have Y 
oeen initiated within DOD to provide cross-functional integration within the Defense Finance and 
Accounting Service (DFAS), the Defense Logistics Agency (DLA), and Transportation 


The remainder of this section provides the baseline of the Dll's capability to support the EDI portion of 


4.1 EC and EDI Infrastructure Scope 


The DOD EC and EDI infrastructure that has been implemented is comprised of hardware software 
communications, policy, procedures, and personnel to enable the processing and transmission of 
business transactions between trading partners. The body of standards governing EDI transactions is also 
included. The key components ot this infrastructure are illustrated in Exhibit 4. f below. The flow of 
transactions from a DOD Automated Information System (AIS) to a trading partner (TP) is also shown. 


vf?' c I % S ' Vhere demonic transactions are passed from the gateways to the 

? lSSUC t0 thC tradmg ?****■ Gateways (GWs) represent a front-end 
process to the AIS platform. VANs are commercial entities in the business of distributing electronic 
transactions to an intemauonally spread customer base. The DISA Compliance Test Facility (CTF) 
conducts testing to confirm that the EDI output files are compliant with appropriate standards and 
federal EDI implementation conventions. Trading Partners must successfully complete the testing 
requirements and the EDI registration process to become a trading partner and exchange transactions 
any C.vthan or DOD activity. DliSD(AR) has established CCR to provide a SEE all 
vendors register with the Government. The Customer Service Center (CSC) is where all EC and EDI 
functional, technical, configuration and software questions and/or problems are answered/resolved. 
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Exhibit 4.1 - Boundry of EC Infrastructure 

NEPs ? GWs. the CCR. and the CSC are in most cases located in Defense Megacenters. The network 
connecting EC and EDI components is the NIPRNET. The DISA-manaaed EC proaram provides 
funding for the operation, maintenance, and upgradeof EC-dedicated resources in the Defense 
Megacenters. Note that the EC infrastructure managed by DISA does not include connectivity between 
GWs and AISs, connectivity between VANs and trading partners, or the AISs. 

The EC and EDI strategy extends to all participants in Federal procurement. Exhibit 4.2 depicts the 
many elements at the Federal, Defense and commercial levels. Federal EC and EDI is composed of four 
layers: Federal Civilian, Defense, the EC Infrastructure, and the commercial segment with which the 
Government does business. 

In the center lies the Executive Branch and Federal Civilian Agencies which issue Executive Orders, 
formulate policy and create regulations. Also included are the agencies that need to do business, both 
commercial and inter-govemmental. Note that EC policy making and regulating are functions that 
overlap into the Defense layer. 
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The Defense layer represents the rest of the Government's business oriented organizations EC 
interactions with the commercial sector rely on and pass through the EC Infr astructure which is 
2?®““ [_^ d maintained by the Defense Information Systems Agency. The EC Infrastructure includes 
SSxS 7 ?’ Application Programming Interfaces (API), Electronic Commerce Processing Nodes 
(DISN) Contmmty ° f °P erations (COOP) services, and the Defense Information Systems Network 



Exhibit 4.2 - Composition of Federal EC and EDI 


The overall Command Control Communications Computers Intelligence for the Warrior (C4IFTW) EC 
and EDI strategy makes use of the centralized network services provided bv the Defense Information 
Intrasmicrure (DII), rather than by building its own network infrastructure.'Tne DII is described in detail 
in the DISA document DII Master Plan. Version 4. 0, dated 26 April 1996. C4I supports the Global 
Combat Support System (GCSS) initiative. This initiative provides a common foundation for 
coexistence and integration of automated information systems to provide combat support. The primary 
fonctton of GCSS is to prepare common components of the infrastructure so that the Central Design 
Activities (CD A) can develop systems that successfully interface with the common infrastructure." 

To meet the timelines established bv the DOD and Federal EC Process Action Teams, DISA used 
existing assets to rapidly deploy an initial DOD infrastructure by March 1994. On 30 June 1995 the 
infrastructure was upgraded to increase processing capacitv and* improve speed-of-service This’ 
infrastructure is illustrated in Exhibit 4.3. 
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Exhibit 4.3 - Current DIS A EC/EDI Infrastructure 


4.2 Current Capabilities Baseline 

The basic EC and EDI requirements were identified in Section 3. As more specific user requirements are 
f, < J. entl ! 1 5 d , and documented m the appendices, a detailed picture of required capabilities can be drawn 
Specmc requirements" means data such as transaction sets, volumes, frequency, timeliness backuD 
and security. ’ 

4.2.1 Functionality 

The NEP and Gateway systems (and eventually Version 1 of the ECPN) maintained bv DIS A satisfv all 
of the functionality requirements stated in section 3.1 with the exception of accounting and billing 'and. 

jumP se ^ ss - DISA is in the P rocess °f developing a fee for service structure to include acco = untin" 
and billing. DISA is also examining several alternatives that will provide interoperable end-to-end 
directory services (Defense Messaging System (DMS), ECPN. Defense Mesacenter (DMC) DISN 
etc.). - . ’ 


ECPN is the result of combining gateway and NEP functions into a sinale environment. New hardware 
and software for this new functionality is being fielded and tested at DMC Ogden, DMC Columbus and 
d 1 ® DIS A COOP and Test Facility (DCTF)in Slidell, LA. CCR functionality will be intearated into the 
ECPN as it matures and will eventually provide the needed directory services. 

4.2.2 Central Contractor Registration 


Central Contractor Registration is one of several major activities that allow the Federal Government to 
present a single face to industry'. Begun in September, 1 994, its development is in two phases. Phase I 
identified initial functional requirements and the database structure, and provided a capability to perform 
initial data validation. Phase H will add several enhancements, including more robust data validation, 
EDI .transactions (XI 2 824, 838 and 997), audit and administrative functions, and interface software that 
permits on-line registration and queries. Exhibit 4.4 depicts the current CCR registration and validation 
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activities. 
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Exhibit 4.4 - CCR as of March 1996 
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Exhibit 4.5 - CCR upon Completion of Phase II Development 
4.2.3 Backup Capability 

S e c E r C r P! £ maintain ' d b - v DIS A will satisfy all of the stated backup requirements Exhibit 4-6 denies 
the be^ii!S^f C ^l7 0 roo d p C!I0n pr0CeSS, n S . and ^“P Processing (COOP) that will be available by 

LportFa^$^^ 
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Exhibit 4.6 - EC Infrastructure 


4.2.4 Security 


4.2.5 Developmental Testing Support 


Command (JITC) acts as a pseudo-atewav and oseudo V AM £ l ~ • Jo,nt Intero P era bihty Test 

across the network during testing ^rt^Z^tSir ““ *“ 

4.2.6 End-to-End Reliability and Auditability 
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DUSDrAMcfto nerf 0,000 per da ‘ y - DISA is working closely with DLA^Sd 

DUSD(AR/EC) to perform volume testing to ensure that the srowine transaction ~ 


Tn ® E £ PN p I2 vides “ enhanced audit trail of transactions to ensure end-to-end reliability and 
SSdon 13,1 inCl “ dCS automa,ed « Ior ^ling, notifications id proVides 

1 . 2.1 Scalability 

^^.P^wns designed from a hardware, software and co mm unications DersDective to meet the 

expandmg EDI workload. The infrastructure currently han dles son ’ , tneet the 

mnndn, t* i cnn nnn J. . . cuirenuy nanaies 2j,500 transactions per day with a future 

DLA and 

growing transaction demands can be met. 

4.2.8 Use of DII Components 

The EC infrastructure design included the use of existine hardware software and 
to process smdard transactions. As technology evohSffi hScS^dved^ Xte 

5SS ^nb S p°Sg^vSet(CO°g ST 

4.2.9 Use of Off-The-Shelf Products 

The ECPN makes extensive use of off-the-shelf products. Exhibit 4-7 Present ECPN Canahilities 

° ff ^ ^,(00^ tta, Off 

4.2.10 Data Standards 


communications assets, 
meet 


p^SSSSSSStSSSSSa 

contigurauon manager for DOD EC/EDI standards. 1S me aesignated 

^andard? Idforaiation Technology (IT) Standards Program, the bulk of information technology 

imporemce to^DOC^EDf U ' deS ““ COOrdmaES tffora ° f other S™PS <1>“ develop standardly 0 " 3 “ 



S of 9 


1 1/13/96 S:l( 


* i .1 ati citC^ Vy i 


Present ECPN Capabilities 


■ ECPN 



• GOTS 

- GCCS SOFTWARE APPLICA 
-GENWATCH 

• COTS 
-UNIX HP1 0.1 
-ORACLE 

-GENTRAN: MENTOR 
-C++ 

- XTERM 
-NETSCAPE 
- REMEDY 

- SYSTEM MANAGEMENT TOI 
-OPERATOR TOOLS 


Exhibit 4.7 - ECPN Software Requirements 

‘ 1 }^ 0rma “ 0n a ^ out specific transaction sets and implementation conventions suDported bv 

the DIS A. infrastructure can be found on the World Wide Web at the URL * 

hnp./Av^vjtsi.disa.mihed^edi-main.html . A description of the standards process can also be found at 
this location. 
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5.0 STRATEGY 


The section describes a strategy to consistently implement EC and EDI throughout the Federal 
Government It describes the actions planned by DISA and other key plavers to ensure that the baseline 
infrastructure discussed in Section 4 is prepared to support the requirements of EC and EDI users. 

Topics discussed include roles and responsibilities, an approach to implementing EC and EDI funding 
standards, migration and the development environment ’ m =" 

5.1 Roles and Responsibilities 

A firm understanding of the roles and responsibilities of all of the organizations that are cooperating to 
implement EC and EDI throughout the Federal government is essential for success. Exhibit 5 1 depicts 
the core missions and the technical components that support them, and Exhibit 5.2 depicts the overall 
relationships among the various players that have roles in EC and EDI 


It is important to note that these relationships are not hierarchical; they are horizontal, with each group 
ot activities contributing its efforts and expertise to the overall EC and EDI program. * 


CORE MISSIONS 
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• Users work with PSAs, the DUSD(AR) Director of EC, and DISA D7 in developing specific EC 
and EDI requirements. 

• The Services and Agencies develop Implementation Conventions to XI2 standardsand pass them 

to the DISA Center tor S tandar ds for approval. 4 

• Services and Agencies participate in the implementation of requirements into the DOD 
infrastructure by working with DISA D3. 




Work with the following organizations in developing 
technical EC/EDI requirements: 

- PSAs 

- DUSD(AR) 

-DISA-D7 

Assist DISA Center for Standards in developing 
Implementation Conventions for XI 2 Standards 

Work with DISA - D3 on the implementation of operatior 
requirements into the DOD EC/EDI infrastructure 


Exhibit 5.3 - Users EC and EDI Roles and Responsibilites 
5.1.2 Acquisition and Technology USD(A&T) 

Tne Under Secretary of Defense for Acquisition and Technology is the DOD Executive Agent for EC 
provides oversight direction for EC and EDI. In that role, the USD(A&T) coordinates the development 
of functional area EC and EDI implementation plans and provides for resource management.See Exhibit 
5 .4 The Principal Under Secretary of Defense for Acquisition and Technologv facilitates the 
reconciliation and resolution of cross-functional and inter-Service and Agenc'v EC issues. 
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5.1.3 Acquisition Reform -DUSD(AR) 

The Deputy Under Secretary of Defense for Acquisition Reform [DUSD(AR)] is the PSA resDonsible 
for insertion of EC technologies across DOD. responsioie 

The DUSD (AR) has approval authority for ail joint DOD and Civilian Agency initiatives and for the 

nnTS^Sr^ 011 of legacy systems to accommodate EC and EDI. DUSDfAR) also fWk- 
DOD s EC and EDI initiatives that are within the scope of the DOD EC and FDf nniw f so " n “ s 
the correction of EC practices that impede BPR. EDI P ° ilCy md facilltates 

ACQUISITION AND TECHNOLOGY 


EC AN D E D 1 1'R Q LES-i -A N DR E S P 0 N S IB I L I T 1 E S 


| U SO CAS T~ 

The DOD E xecutlve Agent for EC 
Provide EC p olio y direction , 
oversight, resources m anagem ent, 
and coordination o f req uire m ents, 
and develop and maintain a 
D 0 D -wid e E C im plem e ntation plan 
R eview im plem enting docum ents 
sup plem enting th e E C Directive 
Advocate and provide the necessary 
budget author it y to support DOD 
—directed initiatives 

POUSDfA & T ^ " 

Facilitate the re co n c ilia t io n and 
resolution of cross-functional and 
inter-Servics and Agency EC issues 
forthe Departm ent ofD efense 


D U SDfA Rl 

- PSA responsible fo r in se rt io n o f 6 C 
in ail developm ent, m odernization, or 
prototype of legacy and m igration 
system s as nom mated by the P SAs 

- Fa cilitate .coordination offunctionai 
requirements for EC initiatives 
aero ss 0 0 D 

- App ro ve all Joint 0 0 D and Federal 
civilian agency initiatives funded by 
0 S 0 

- Facilitate the correction on any EC 
practicesthatimpede BPR or 
process im provem ent 


Exhibit 5.4 - Acquisition and Technology EC and EDI Roles and Responsibilities 
3.1.4 Director, Electronic Commerce 

Under the DUSD(AR) is the Director for Electronic Commerce (DUSD(AR/EC). See Exhibit 5 5 The 
Director provides a leadership role as the EC and EDI facilitator across DOD and provides a functional 

n?S a nnn D S ^ ;D7 for cross * flmctlonal requirements collection and integration P The Director also acts 
as the DOD interface to the private sector and Civilian Agencies on EC and EDI functional issues The 

execu [5 s . ousmess process reengineering opportunities, works with the EC user 
community, and develops policies and procedures necessary for EC and EDI. The Director also designs 
ana implements outreach programs, reviews and makes funding recommendations to DUSDfARi for 
new and on-going EC and EDI initiatives, and provides oversight of approved EC md EDI pr^ms 

5 1 .!£jJ ector aiso P rovldes limited tundmg for EC initiatives utilizing EC/EDI technologv in DOD target 
systems. w * © 
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DIRECTOR. ELECTRONIC COMMERCE 
EC AND EDI ROLES, AND RESPONSIBILITIES 


Facilitate the participation and interaction of the functional user com mun ity 
a cilita te th e collection and coordination of functional requirements for EC 

across the D epartm ent of D efense 

Principal point of contact with the private sector, contractors and Federal 

civilian agencies for the Department of D efense on EC matters 

Principal point of contact with Federal civilian agencies on government-wide 

fcC initiatives, systems, policies, and business practices 


Exhibit 5.5 - DUSD(AR) EC and EDI Roles and Responsibilities 
5.1.5 Principal Staff Assistants 


The PSAs to the Secretary of Defense and the Joint Staff establish policv and plan for mission 
Support 1 ^ctSns UdmS ^ requirements for Command ^ d Control (C2), Intelligence, and Mission 


PSAs determine EC and EDI goals and high-level functional requirements and derive commitment 
“Om and provide resources to the organizations to implement EC and EDI goals. 

• PSAs provide direction on developing and deploying EDI caDabilities within their purview and 

ensure the direction is observed. * K ' 

Organizations responsible tor standardizing business processes and information svstems across DOD 
such as Joint Logistics Support Center (JLSC). Defense Procurement Corporate Information 
Management Systems Center (DPCSC). US TRANSCOM (USTC) J4-LT. are chartered to plan 
develop, coordinate, and implement improved business practices, and to oversee the development of 

automation to support these practices. These organizations are functionally aligned with the PSAs These 
organizations: * * *• luCiC 

• Sponsor DOD strategic uses of EC and EDI in their functional area. 


• Provide functional input to the DOD EDISMC functional working groups. 

• Assist DOD applications by providing guidelines to create user defined format files fUDF') that 

can be mapped to comply with federal XI 2 ICS. v J 
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Exhibit 5.6 - PSA EC and EDI Roles and Responsibilites 

5.1.6 DISA 
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Exhibit 5.7 - DISA HC and EDI Roles and Responsibilities 
de&ed bfSc^S 

ccSpSrsiacS^^i? an °, f *? disa s»ss^.Ssss* 

and the Electronic Commerce Processing Nodes'IcPN^ToMa CotobSSd Og£n. IC Columbus - 

5.2 Approach to Implementing EC and EDI 

The preceding paragraphs discussed the roles and responsibilities of various non nm er,;„t- 

identified, requiremetus'are developed, priorities are set mSose \ud°“,?' 'h th ? P , r0 , CMS proj ' cts “* 

° f ““ Pr ° duc ' Ts ™ CtP-D tS “escribed in 

5.2.1 Identify EC and EDI Functional Area Opportunities 

si ssaasar 




opportunity may represent a need to solve a specifically identified problem, or it may represent a wav to 
business process. The mechanism for this activity is a high level Overarching IPT 
[JS ^ Penodicaily to evaluate candidate opportunities, prioritize them and provide overall 
KuS triS 6 ™ 011 ° f thC UUUatives ' d USD(AR/EC), in its role as the DOD PSA for 

5.2.2 Establish Functional Working Groups 

In order to ensure a continuity of focus during planning, development, and implementation of EC and 
EDI projects, functional Working IPTs (WIPT) will be formed. Each WIPT will consist 2f 
representatives from DUSD(AR/EC), DISA and the user's organization(s) with ioinUhahmen 
representing both the functional and technical communities. They will meet perioScd^Sdrscuss 
requirements, work out interface issues, and resolve other issues that may arise. In crostLcS 
implementations, it will be necessary to involve all functional areas in the IPT activities. 

5.2.3 Develop a Functional Requirements Document 

The most important product of the IPT will be an electronic Functional Requirements Document (FRD) 

DOD* * ^ieD IS At° accurately assess the impact of the project on the 
DO “ EC/EDI mfrastructure.lt will allow DISA to identify what, if any, new technical requirements are 
needed to support the project's functional implementation. It will also provide information needed to 
evelop schedules, implementation conventions, testing requirements, and installation plans. 

5.2.4 Determine Priorities, Costs, Budgets, and Schedules 

DUSp (A IVE C) in conjtmcrion with [he Principal Staff Assistants work together to develop the 

Pn0nt ‘? ? r EC/EDL .The development and enhancement of DISA's infrastructure is based on 

eve? so to ^baWiew Tdod pTand Fnr qU ^ mea? f ° r ^ P^"*™ 5 is done at the corporate 
level so mat a g.obal view of DOD EC and EDI can be maintained, resulting in a coordinated effort that 

Sedulp'i^ ^ H V1S1 ^^ hty and support. Estimated costs of the projects are examined and budgets and 
scnedules are developed and priorities established. 

o.3 Funding 

In general die Office of the Secretary of Defense Principal Staff Assistants, Services, and Agencies 
should fund implementation of EC so that, where it is appropriate, the Departments paper-based business 
processes employ EC technologies. The Components and their respective Program 

rw, d r ate SUtflCien ■ reS f, UrCSS t0 en$Ure aI1 risnuioTi and new starts are m full compliance S EC 
standards. Components snould continue to implement and expand the EC program in all appropriate 
functional areas and ensure practices are compliant with EDI standards. Components should continue to 
support the use or EDI as the preferred way to enhance the Departments abilitv to exchange information 
within the DOD, with other government agencies, with allies, and with industry. ‘ = information 

Currently, users of the DOD EC and EDI infrastructure are not required to reimburse DT^A far that 
usage. Beginning in FY99 customers will be required to reimburse DISA for use of the EC/EDI 
inirastrucmre on a tee-for service basis (Defense Business Operations Fund (DBOF)) DISA is working 

5.4 Services and Agencies 

Services and Agencies will be responsible for maintaining their functional applications oreoarina them 
for interfacing with the DOD EC and EDI infrastructure, ’training operarioS^iSIlS^- 
and maintaining the hardware platforms that host their applications. " ’ 

5.5 -Migrating to Future Infrastructures 
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DISA is currently engineering a more efficient infrastructure which will co-iocate the NEP and GW 
functions into Electronic Commerce Processing Nodes (ECPNs) and standardize the services provided at 
each processing sue. DISA is now deploying the new architecture (ECPN Version 1.0). Exhibit 5 8 
depicts this new EC/EDI infrastructure architecture. 

Capabilities that are built into Version 1.0 include: 

• Increased user transaction capacity 

• Enhanced communications 

• Stable and reliable processing code 

• Hardware architecture designed and optimized for EDI tasks 

• Fully accessible audit trail and reporting tools 

• Research tools provided to customer service center 

• Multi-strategy Continuity of Operations Plan (COOP) 

The outyeararchitecture will evolve as the Common Operating Environment (COE) and supporting 
common uffi^structure evolve. For instance, the DMS will be used to provide standard messages to 
elements of the COE after DMS reaches Initial Operating Capability (IOC). Use of DMS will § be 
mtegrated into EC/EDLoperations. More transparently, EC/EDI rides whatever transport layer is 
provided by the NffpiET. As NIPpiET evolves. EC/EDI will make use of its expffi Slides. 
ExhibkTs^ mfiastructure beyond FY96 (with ECPN Version 2.0 implemented) is depicted in 

Capabilities that are built into Version 2.0 include: 

• Data load leveling 

• Transaction error identification tools 

• EDI infrastructure viewing tools 

- Filtering by Service/Agencv 

- Filtering by industrial sector : 

• Statistical analysis on transaction sets 

• Automated report generation 
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APPENDIX A - DOD DUSD(AR/EC) 


1.0 Background 

mnn f \ EleCtr0niC Commerce (EC)/EIectromc Data Interchange (EDI) to support Department of Defense 
(DOD) procurement processes has been under consideration for some time. A 1988 Deputy Secretary of 
Defense memo called for maximum use of EDI, based on 10 years of DOD EDI investigation and^ 
, 990 ’ De *T i y ana § ement Review Decision 941 stated, "The strategic 5 goal of DOD's 
e ? c “F ls t0 P ro '? de ^e department with the capability to initiate, conduct, and maintain its 

“ mtemai losis,ics ’ con,ia ' :,ii,s ’ ^ fin3 ” cial “ h * i “ withom 

SSw 93 ’ DOD Acquisition Law Advisory (Section 800) Panel submitted a report to 
focSP .^concentrated on changes that would streamline the defense procurement process in the 
1990 s , when dollps are expected to be fewer, work forces smaller, and superpower security threats less 
thf!nL>^° nS th ^ h , undred ? recommendations contained in the report were several thataddressed 
^ inT d n^n°5- e 6C + f ° mC pr0CUrement 9 0tl ce and contracting methods, The rapid implementation 

2^9 directly supports acquisition reform and the recommendations contained in the 

Streamlining Defense Acquisition Laws Report, particularly the recommendation to raise the s mall 
purchase threshold to a $ 1 00,000 simplified acquisition threshold. EC contains the iifoerent cap^bilitv to 

ssr 3,6 ^ to - refe,m ~ 

On September 7, 1993, the National Performance Review (NPR) recommended that EC/EDI be 
expanded within the federal acquisition system. One of Vice President Gore’s recommendations for 
procurement specifically calls for establishment of a Government- wide program to use EC for federal 
acquisition below a specified dollar threshold and for those acquisitions and orders that use simplified 

SeC/EDI wifofn ^DOD 56 d ° CUmentS provide clear evidence dlat *** « support for the expansion 

it 

Colleen A. Preston, Deputy Under Secretary of Defense (Acquisition Reform) has taken definitive nrrion 

°Ia?a e aememrrfvn°p n My l9 ?' ^ Piston directed the Chairman of die Corporate Information 

Management (CIM) Procurement Council to establish a Process Action Team (PAT) to assess current 

contacting wabUmes m Je DOD EC/EDI infmmicmre. Building upon cunanPDOD caplbilifc! the 
DOD EC ui Contracung PAT was tasked to develop a comprehensive planfor implementing an EC 
approach for procurement functions consistent with the .American National Standards Institute (ANSI) 

reLv^Tpdic v issues. 2 ° P 2 P ^ m§ eSUmate f ° r the resourcss ^d sched ule required, and to identify 

The EC in Contracting PAT membership reflected a broad cross section of Militarv Services and 
Derense Agencies working on a full-time basis for 60 days. The diversity of the EC in Contracting PAT 
die needs and concerns of all DOD components were addressed during the creation of the 
tluoughout SeDOD P theret0re ’ re P resents a comprehensive approach for implementing EC 

1.1 Objectives of EC and EDI in DOD 

The EC in Contracting PATs Charter directed that certain actions be performed during the review. 

These specific tas kings became the team’s objectives and were assigned to working groups within the 
EC in Contracting PAT itself. This allowed the working groups to focus on specific objectives during 
review and site visits. Also, inputs were solicited from both private and public entities based on tiS EC 
m Contracting PAT’s objectives All information compiled from research, site visits Ld response! to 

wefe'S^Tlows^ Sharea VVIth the erUlrC tCam ‘ The ° bjectIves that S u ‘ded the EC in Contracting PAT 
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* £ V S\, D ° D £C = a P abiiit y to support competitive procurement and improved access and nonce 
to small businesses in support of increasing the simplified acquisition threshold 

* Identify any relevant EC policy issues related to near-term and long-term EC implementation 

’ V^AddS nJw ' T ™aM e ? tUre (CUmnt “ d &ture) “ inctod e 1 hubs . netwo^i/gateways 
Networks (VANs , etc to support EC. Identify areas for standardization (e . 
EC/EDI data conventions, VAN certification, vendor registration etc 'i The nnmn» -Af *' \ i • 
to .dentify likely future developments for which options should be maL^effihe f * “ 
implementation of current and available capabilities and systems 

I KS* iSSUeS anc i ass “ s P° te ? tiai of risk and uncertainty related to near-term EC 
2r £ P M C °? pre f ensiVe ^Fomentation plan with specific time-phased recommendations The 
plan should identify options, including estimates of resources required to achieve a Sd ™ 

? contracting v vithin DOD. Additionally, initiatives to publicize Educate 
Government and Industry on EC contracting activities would be addressed. 

* nd mp ementation 311(1 deployment of a system that would provide a "single face to 
1.2 Functional/Technical Assessment and Analysis Results 

An^sessmentof EC/ED 1 capabilities to exchange data related to the procurement process as thev exist 
witinn the DOD and other federal agencies (e.g., General Services AdListrSf^O^SMU 

aspec t^o ^e°c ument DOD hr 3356551116111 reviewed both the functional and technical 

aspects of the cun-ent DOD EC/EDI capabilities in contracting including, but not limited to Integrated 

fSACONS Inn SAMMS? Procuremer ! t System (ITIMP), Standard Automated Contracting System 
(bACONS-EDI), SAiVnviS Procurement by Electronic Data Exchange (SPEDE1 Government ' 

Acquisition Through Electronic Commerce (GATEC), Menu Assisted Data En£y SyS (VMES) 

“t" [ “md°es^d “e'p7oymSl ACCOlmting (APADE) ’ 0rder 10 deKmin = ">!e 

In particular, the EC in Contracting PAT assessed the current capabilities of the EC/EDI infrastructure 
and systems to support simplified competitive acquisition under*S25,000, consistent with the ANSI XP 
with improved access, notice, and participation of small businesses, htitiil? tele Tco?wcting PAT 

?S S r£n? 7 np0n< ? ts (Navy, Army, Air Force, DLA, DISA. DFAS md DeCA^S 
independent EC/EDI solutions for their automated small purchase procurement svstems A strategic aoal 
of DOD is to present a "single face to industry." Therefore, the EC in ConSS^ § 

Fn^addPnn * c ° mmon standard m the ^distribution of EC/EDI actions to DOD's trading partners 

In addition, the EC m Contracting PAT examined ways to assure that improved notice of pendin® 
procurements could be provided to insure participation by small businesses. P = 

In support of the findings of this EC in Contracting PAT, a number of issues required a consensus 
approaerr b> all memoers. Without these basic pnnciples to establish the framework for future 

sSutiMfo*? Ac expaSon i ofFC W ° Uld haVe be - en im P ossi ble to sustain a focused DOD 

solution tor the expansion of EC/EDI with Industry m contracung. The following are several of the kev 

consensus items discussed that represent the baseline functional requirements for consideration in tire 
expansion ot EC in Contracting throughout DOD: consideration m me 

• DOD must present a "single face to industry." 

This issue was clearly the most important to the EC in Contracting PAT. A "single face to industry" is 

n™ eda5 perI °, rm ? nce ? r EC by Ae Government using EDI in accordance with federal information 
processing standards and a common set of business practices and operational principles It m™t be a 
solution which allows the vendor to be able to process the transaction to and/or from anv DOD activity 
minimally subscribe to one V AN to do business with all DOD, and reader onlv once to become a DOD 
supplier (rather than with each DOD component'activity). y ° nCe t0 beCOme a D0D 
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• A single point of entry will be provided by DOD. 

a / ep0sit0ry ^central registration of electronic addressing 'information, tradin- 
agreement information, trading partner profile, and other pertinent supplier information This 

be accessible by 311 applications which require authorized access to this data! It 
will not be restricted to procurement system access only. The contractor registration nrocesc ;« .WnrUH 

to replace the Standard Form (SF) 129, Commercial And Government Entity (CAGE) code applications 

r d M^ ° C ? 1 P f ° nn L atloa - A capability for use of EDI to coUect and update this da^will be ’ 
established, and will include the ANSI X12 838 transaction set, as well as other transactions as needed 
This will provide a single pomt of entry to obtain access to all DOD requirements. d d * 

P2P ^ use ANSI X12/EDIF ACT for administration, commerce, and transport. 

• ^ be m acc0rdance ^ ANSI X12/EDIFACT for administration, commerce, 

nfSF!?* fPOD inventions requires inter-service coordination and a central point of contact 
ri^i?- SA r p nsib i e for . c onfiguraOon management, with Procurement CIM sponsorship and 
Industry mv^vement Fimctional data decisions will be resolved by the appropriate Office of the 
Secretary of Defense (OSD) sponsor. In order to facilitate the merger and avoid redundant development 

^ W ? 1 hf mad f m -fa*** devel °P ment of implementation conventions to select the P U 
appropnate standard mandated by the using comm uni ty 

• Architecture will support all other DOD operational or functional requirements. 
^r e ?s D fiict^S: arChiteCmre WiU reCOgnize Md acc °mmodate the operational requirements of these 

1 . Procurement 

2. Contract Administration 

3. Transportation 

4. Supply Management 

5. FinanciaLManagement 

6. Maintenance 

7. Engineering 

■ . ' 

• Use of commercial and Government products. 

TTie EC infrastructure will be based on approved technical standards that support DOD open svstems 
objectives that mclude maximum use of Commercial-Off-The-Shelf (COTS) and reusable ' 
Government-Otf-The-Sneit (GOTS) software products that have been tested, accepted and are 
supportable qv the Government. DOD will issue a supported list of COTS and GOTS products A 
central repository' for reusable GOTS products will be identified. P ’ A 

• Use of VANs. 

™ e _D° D EC/EDI architecture will provide connectivity to public and private VANs to exchange 
EC/EDI transactions with trading partners external to DOD. This includes use of dedicated lines 

S“of EbitT s “ dmS P “" erS - VANS may ° ffer bulletin - Wd ttan directed 

reoufifm rf^pr/Fnrh p5rspc:tiv ' ° f “ hat Industry has developed in the area of EC/EDI and what thev 
PAT cni,v?r !FL DI . business , vwth the Gove mment, it was recommended that the EC in Contracting ' 
PAT solicit Industry input on their initiatives. A standard questionnaire was provided to kev Industrv 
associations representing over 9,a00 companies in an attempt to reach the largest possible audience^ 

Based on the responses received from the VAN community, the VANs will suoport anv DOD EC/EDI 
procurement initiative that is standards based and underpinned by a single set of policies and procedures 
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2.0 Basic Requirements 

supported by 

description of each of them and also identifies which xi2 transaction s“ts ml £7^““^ * ^ 


PSA Project ID 

Project Title 

Procurement/ Acquisition Reform 95DLA 005 

Commercial And Government Entitv Codes 

Procurement/ Acquisition Reform 95NAV 0 1 1 

Food Service Management 

Procurement/ Acquisition Reform 95NA V 0 1 6 

EDI Afloat 


3.0 Analysis and Considerations 

The existing Defense Information Infrastructure (DII) satisfies manv nfnnn-e „„„• r 

electronic transactions between trading partner %ere 2e ho^r ^92 3 for moving 


Attachment 1 to Appendix A 
Procurement Projects Supported by the DOD Electronic Commerce Office 


PROJECT 95DLA 005 

Objective: COMMERCIAL AND GOVERNMENT ENTITY (CAGE) 

SfWen?o?r^p d C ^ G£ " EDI „ Systern wil1 Provide greatly improved turn around times in the 

vendorckmograohics ^“.^IfcfSSSS'SSSjSSSS d fT , "H f ° r 
with the government using EC/EDI. gistration mechanism for vendors doing business 

Project: 

code is required for suppliers participating in the Federal Supplv SvstemfFSS't Civilian 
A = en . ci . es ’ suc ^ ^ National Aeronautical Space Administration (NASA) General ^prviL»c 

Defense Federal Acquisition Regulations Supplement at DFARS 004 6 remiirp -frarp a ' 

procurement in excess of $25,000. PP ’ Utv *** " U4 - 6 rec ! mre a CAGE code on any 


On December 20, 199 j the Electronic Commerce Action Team fPf’AT'i ;<. 0 „ a j _ , . , 

other things recommended a "single face "Tgl^ent feTS^S^^ n C L'^ 1Ch “Tt, 

government. Such business should be conducted using Electronic Commerce (EC) and Elecnlm^Dam' 
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kte: (EDI) convennons - Based upon this recommendation the Defense Logistics Service Center 
gLSC) and Defense Automated Address Service Center (DAASC) jointly developed and deploved a 
door to door' mechanism for processing CAGE codes requests using 838 "Trading Parmer Profile" 
transaction sets. This mechanism became operational in June 95 by processing the Trading Parmer 
Profile transactions for the Central Contractor Registration (CCR) system. 3 

The CAGE/EDI system has been funded for further automation under DOD's Office of Electronic 
Commerce which is under the Deputy Under Secretary of Defense for Acquisition Reform. This 
expanded automation project will be accomplished in four phases, each of which is should be 
accomplished in three months. 


The fully mechanized CAGE/EDI system will provide greatly improved turn around times in the 
assignment of CAGE codes as well as a comprehensive on-line information dissemination system for 
vendor demographics. The CAGE/EDI provides a "seamless" registration mechanism for vendors do in* 
business with the government using EC/EDI. = 

PSA: Acquisition Reform/Procurement 


Lead DOD EC/EDI PM: DLA, POC Terrence Hunt 
(616)961-4856 

Transaction Set: 838 Trading Parmer Profile 


Status: Deployment 

Deliverables: 

Match no Match Capability 

Automated CAGE A Assignment 

Database Expansion 

i 

Expanded Information Dissemination 


PROJECT 95NAV Oil 

FOOD SERVICE MANAGEMENT AUTOMATION 

Food Service Management (FSM) is the only certified automated information svstem used in the Naw 
to support general mess (GM) financial and inventory management functions. FSM, developed more * 
than a decade ago, bases all functions and operating decisions on a set of policv and procedures designed 
to support paper-based operations. In short. FSM automates manual records keeping functions 
hardware configuration management and support for FSM has not kept pace with FSM software 
development: as a result many of the 477 Navy general messes are operating on obsolete hardware under 
approximately 4t> different configurations. FSM is entirely stand-alone and does not share information. 

Subsistence Prime Vendor (PV), a DOD initiative to procure provisions directlv from commercial food 
distributors, provided the vehicle required to help move Navy food service into'a less paper-based 

^™^ Actl ™ eS which P rocure food though PV utilize the Subsistence Prime Vendor Interface 
w-F . V I, an Electronic Data Interchange (EDI) translator which accepts customer orders and 

receipt information and forwards them to Defense Personnel Support Center (DPSC) and to the vendor, 
is labor intensive and requires manual data entry. Procurement, receiving and bill pavment processes are 
inetxicient and cumbersome using current SPVI methodology. DPSC is the information broker 
controlling flow of information to vendors, ordering activities and bill paying activities. 

Naval Supply Systems Command (NAVSUP) has developed a notional concept of operations for food 
service operations which exploits advantages of new technologies and PV initiatives. Enablin* 

w 
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technologies such as bar-coding and EDI will allow Navy food service procedures to be significantly 
streamlined. In addition, data flow directly to the parties requiring it to perform their functions 

added information brokers are eliminated. American National Standards Institute (ANSI) 

.yt ^Dl transaction sets will be used in all phases of the procurement and bill payment. Information 
wiH be shared between the ordering activity, vendor, bill paying activities. Defense Finance Accounting 
System (DFAS) and DPSC. In an afloat environment, FSM will forward procurement data to the EDI 
translator via the shipboard network. Ashore, FSM will forward data via phone modem directlv to a 
shore-based translator. ! 


Under the NAVSUP concept of operation, FSM users will be able to place orders, certify receipt of 
provisions and authorize payment of dealers hills using EDI transactions. Information provided from the 
a?. cataio § s a? d shipping notices will be forwarded using EDI and directly uploaded into 
FSM. These shipping notices will also provide Uniform Product Code (UPC) information which will 
further enhance benefits derived through bar-coding. Bar-code information will be available to an 
ordenng activity before any provisions are ever received. Time and labor requirements to perform 
provisions receipt and stowage will be significantly reduced while inventory validity increases. Vendor 
bills will be certified using EDI transactions and paid via electronic funds transfer. Eventually all 

L;u p ji°r7 ien,atl0n , wi11 be re P Iaced EDI transactions. Fully implementing EDI as defined in 
the NAVSUP concept of operation will allow several non-value added functions and costs to be 
significantly reduced or entirely eliminated. EDI will facilitate the efficient sharing of information 

eliminate paper transactions, minimize manual data handling and associated errors and reduce non-value 
added processes. 


PSA: Acquisition Reform/Procurement 

Lead DOD EC/EDI PM: LCDR Morris Caplan 
(703) 602-36B6 


Transaction Sets: 

821 Financial Reporting 860 Purchase Order Change 
824 Application Advice 861 Receiving Accept 
832 Price Catalog 864 Text Message 
850 Purchase Order 865 Purchase Change 
857 Shipment Notice 997 Functional Acknowledgment 

Status: Prototype 


Hardware for shipboard upgrades of 190 ships. .Analysis & Systems Integration 


PROJECT 95NAV 016 
EDI AFLOAT 

The shipboard community uses multiple legacy supply and financial svstems to meet the reporting 

£ oraccoumin ? and inventory data required by the Defense Finance and Account Sendee 
(DFAS) and the Government Accounting Office (GAO). Current afloat legaev systems are bein* 
rep laced by a Relational Database Management System (RDSMS) and 4th Generation software "(called 
R-S uppIvjL Additionally , current legacy financial programs will be replaced bv DFAS interim migratory 
systems. The afloat systems do not provide data real-time or in the detail required bv the interim " 
migratory accounting systems. Discrepancies due to manual data entrv and the time-la* caused bv 
numerous paper/tape transactions going back and forth between the ships and shore activities *et‘ 
compounded while at sea. A 45 day accounting cycle exist because of the time involved in receivin* 
oo ligation and billing Information from afloat and ashore activities. To provide real-time input detail 
obligation and expenditure data, and allow for independent development of software: Electronic Data 
lntercnange (EDI) is seen as a proven mechanism to which will allow these goals to be met. 

The Navy will use EDI for data exchange in developing its afloat software and migratory accounting 
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systems. We will also use this medium to facilitate the movement of financial data ashore bv reducine 
complexity and- by providing timely data, thereby reducing the accounting cycle. Additionally EDI will 
provide for increased asset visibility, compressed telecommunication transmissions, and allow’ the Naw 
to consolidate and standardize its business practices afloat and ashore. 

EDI coupled with R-Supply will also provide the Fleet with the ability, to take advantage of numerous 
Defense Logistic Agency (DLA) initiatives involving the use of EDI within the private sector These 
initiatives involve customer direct ordering of various commodities from vendors. Currently ' 
pnara^cuacal, medical/surgical supplies and food items are ordered electronically using interfaces. In 

hlu^f TI? 6 'if ° fee ^? 0mc cataiogues P rovlded via EDI, and resident in the afloat software would 
be used. Thus, allowing the customer to select the required Items and transmit an order via EDI for 
delivery to the afloat activity. 

PSA: Procurement 


Lead DOD EC/EDI PM: Navy, POC CDR Doug Ballou 
(703) 607-0835 

Transaction Sets: 


511 Requisition 855 Purchase Order Acknowledgment 
810 Invoice 856 Ship Notice 

821 Financial Reporting 857 Shipment and Billing Notice 
846 Inventory Inquiry 858 Shipment Information 
850 Purchase Order 888 Item Maintenance 

854 Shipment Delivery Discrepancy 940 Warehouse Shipment Notice 
Information 997 Functional Acknowledgment 

Status: Prototype 
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APPENDIX B - DOD FINANCE AND ACCOUNTING 

(POC OUSD(C)) 


1.0 Background . 

The Deputy Secretary of Defense directed the establishment of a working group to deveioo a course of 
action to alleviate *e systemic problem of Unmatched Disbursements (UMDs) Under tL of 

the Acquisition and Financial Management Panel, co-chaired by the DOD Comptroller andte Principal 
Deputy Under Secretary of Defense (Acquisition and Technology), the Acquisition and Financid P 
Management Working Group was chartered for that purpose. Ari unmatched disbursement i^any 
disbursement received by an accountmg office that cannot be accurately matched to the correct 7 
obhgation record. As of June 30. 1993, DFAS reported S19 billion in uLnaSdU teemenB 
Contract payments made up the majority of the dollar value of unmatched disbursements. 

The report. Eliminating Unmatched Disbursements - A Combined Approach, prepared bv the 
Acquisition and Fmancial Management Working group, presents 48 recommendations focusin* 
pnmanly on short and mid-term improvements. Within the recommendations a central theme to make 

233ES “ dUPliCate d - enay “ d t0 * tooly distribtSn 

DF A^ndnnn^Sf S Gr “l P rep0rt ’ haVe • ' Mn , fimher » refine the recommendations. 

DFAS and DOD now have underway a program to implement the final recommendations of the 

Working Group and has already completed many of these actions. The technical implementation of EDI 
wUch ifmSn^ by S E * POrti ° n ° f ' DefenSe formation Infiastructnre (Dll) 

Fmanc * P* Accounting Service (DFAS) is responsible for providing financial, accounting 
disbursing, and reporting services to the various Department of Defense aaencies and other 
governmental entities. DFAS operates financial applications at 21 operating locations that report to five 
DFAS centers- which report to DFAS Headquarters in Washington, DC. P 

5 i 

location to location^ aCC0Unting func:ions ’ each center performs specialty functions that vary from 


The following is a list of those specialty functions: 

• DB OF Accounting and Payments 

• Support Services 

• Security Assistance 

• Customer Service and Performance Management 

• General Counsel (and Garnishment Operations) 

• Financial Operation Review and Performance Assessment 

• Contract and Vendor Entitlement 

• Military and Civilian Pay 

• Travel Pay 

• NAF Accounting 

• General Accounting 

• Transportation 


Each operating location is supported by a Defense Megacenter (DMC) as shown in Exhibit A.l. 

As a_core business function. Finance and Accounting has required extensive sharing of data and 
vermcation of accuracy of data. Various forms of data sharing have been developed including paper 
9-uac.< tape, proprietary data formats over Defense and private networks (Defense Data Network 
frSST Dlglta NerW0r * C etC °- Flle Transfer Protocol, and Electronic Commerce/Electronic Data 
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DFAS ARCHITECTURE 



owe - Roe* mine 


Exhibit B.l - DFAS Architecture 

In addition to exchanging information with other DFAS svstems and DOH nr a c 1 

exchanges or shares business information with 

n’ ° f T reaSUry , and General Services Administration. The term share is used in eSerV6 ’ 
c^oss-functional integration discussions to mean that the referenced n *m‘pc *11 u m t 

data, which eliminates the need to rekev the data and « P 31 * 1 ®? a ^ ^ ave access to the source 

account receivable department. and the ° SA ' S 

2.0 Basic Requirements 

O^C^Cjrw^^h^^e^omdb^Iicy DC^s pratrement s^te^^th dwTIe^ic 1 ^^^ Center 
wno develop and operate the procurement svstems, and with DIS A who is resnons^We fx Agencies 
mamtaimng the EC and EDI infrastructure. * h0 ls res P°nsibie for providing and 

The first phase in eliminating unmatched disbursement is to emhl*» th»» c . . . _ 

Contract Officers (PCOs) to Generate XP 850s descrihino ih*™ * S 7- S 311(1 .Agencies Procunng 
conditions, as well as mv XP 360s for modlLtions m ,ts “ soc ' ated and 

Ttansiarion Service (X12 3050 850 and 860) for the Army. Navy, Air Force and DLA 
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• Compliance Testing of all Service and Agency generated transactions 

• Audit of transaction through the infrastructure 

• Two hour delivery service for all 850 and 860 traffic 

The next phase in solving unmatched disbursements is to implement EDI for pre-payment audit of 
vendor invoices. Vendors normally submit their invoices directly to the DFAS center responsible for 
payment. However, DFAS’s accounting system may not be updated to reflect any contract modifications 
In the past, if the accounting system determined there was a discrepancy, a DFAS payment officer would 
attempt to reconcile the differences over the telephone with the ACO Jd/or the 
me contract writing systems will provide all contract information to the accounting system usine an XI 2 
850 or 860 transaction set. This will enable DFAS’ accounting system and the ACO and PCO databases 
to remain synchronized. The requirements for this phase are: " 

• Translation Services (XI 2 3050 810) from the ACO / PCO to the DFAS Centers 

• One-to-many transaction routing 

• Network Entry Point Services for vendors to submit invoices (XI 2 3050 810) 

SS’ft lVn%™ pl £ ment EDI for contract closeout. During this phase, DFAS will pay the vendor 
l e ? d /S 2 820 Renuttanc ? Advice to the Department of the Treasury to ensure the correct account 
is debited. This same payment information will be supplied to the ACO and PCO This testing is 
scheduled to commence in April 1 996. The requirements for this phase are: 

• Translation Services (X12 3050 810 and 820 ) 

• Electronic Funds Transfer (EFT) Services 

• One-to-many transaction routing 

i t0 - im F I 5 ment u thiS ED U a £ abiIity t0 8,1 D0D procurement, contracting, and accounting 
S Ta T s0 delude exchange of EDI transactions with the Department of Treasury, and anv 
phase fedSra agenCy Wlth wbom DOD conducts business. Requirements are still being identified for this 

nr m d EDI . pr J? jeCt is bei ng funded, at least partially, and supported by . 

DOSD(AR/EC), the DOD Electtomc Commerce Office. Attachment 1 to this appendix contains a short 
description of it and also identifies which X12 transaction sets are being used. 


PSA 

Project ID 

Project Title 

Finance 

95DLA014 

Electronic Funds Transfer 


3.1 Analysis and Considerations 

The main issue impacting implementation is the ability of DOD applications to accommodate DFAS 
W™"? 8 - ? 0me w! lc ? nons - such “ Army's SAACONS, have indicated that much work needs 
Kji? f°?* t0 cha “S' their legacy systems to provide application User Defined Format (UDF) files for 
860s and to comply with X12 version 3(b0 of any transaction set. v 3 

DFAS has a requirement to address and deliver single transactions to multiple locations. Current XI 2 

2 Sin§ i C ^ dressee Pf. transaction. This restriction results in the Service or Agency 
transmitting a UDF for each addressee, which consumes scarce resources and increases the costs of 
doing EDI for the functional area. DISA is working to resolve this issue and has determined there are 

mni e t^u P iT S available - S °rae options are sponsoring a request for change to the X12 standard to allow 
multiple addressees or to build this capability into the Electronic Commerce Processing Node. 

Multiple organizations are setting EDI policy. This conflicting guidance causes confusion for 
bervices/Agencies while they are developing requirements and application specifications for EDI 
projects.To eliminate tlus conflict m policies, the procurement and financial policy offices are 
coordinating data requirements among themselves. The Acquisition and Financial Management Working 
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Group (AFMWG) has been established to accomplish numerous actions to resolve unmatched 
disbursements. Many of these actions involve EDI implementations. 


Attachment 1 to Appendix B 

Finance Projects Supported by the DOD Electronic Commerce Office 


PROJECT 95DLA 014 
Objective- SUBSISTENCE ELECTRONIC FUNDS TRANSFER 

This initiative will provide the Electronic Data Interchange (EDI) transaction for the Federal Reserve 
W1 1 P ro y?de the cash disbursement back to the vendors bank as well as a remittance advice back to 
the vendor. Finally, it will provide an overall audit trail of the financial transactions. 

Project: 

Accounting Service (DFAS) currently pays subsistence invoices using a mailed paper 
check. Tfre annual pnce to accomplish this process is over $6 Million ($65 per invoice for 100 000 ? 
invoices). The current process starts with the determination by the voucher examiner that the invoice 
should be paid and is not completed until the check reaches the vendor via the mails. 

This project will work for the payment of all subsistence vendors. It is an enterprise project and deals 

Thtrrnt C° ncentratl ° n ^ Disbursement (CCD) Transaction with an 80 character addendum record. 
The CCD is a Treasury transaction that works through the automated clearing house of the Federal 
Reserve Banks. First, it will provide the Electronic Data Interchange (EDI) transaction for the Federal 
Reserve. Second, it will provide the cash disbursement back to the vendors bank as well as a remittance 

^sactS^^ 11011 baCk t0 thC Vend ° r ‘ Finally ’ k WiU Pr ° vide 211 0VeraI1 audit traiI ofthe financial 

Because the timely processing of this data is critical (7 day payment of billing) and the importance of 
financial integrity it was determined that it was in the best interest of the Defense Loeistics A^encvs 

fnrcvrl?* rtf r °fi Sr T t0 f keepthe pr0ce ^ in o g within Defense Integrated Subsistence Management System 
(DISMS). The funding for this project ($ 1 84,000) will cover the programming which will be 

Defense Systems Design Center. This programming requires the modifications of 

th°rp d » mnH 1 D SMS , modules r Seven of these modules are in the contracting area while the remaining 
thre*. modules are related to financial processing and payment. 3 


This project in conjunction with the Electronic Invoice Project will reduce the amount of manual 
voucher examination required and will actually facilitate payment to subsistence vendors d^tronicallv 
The enhancement to an electronic payment process is seen as the incentive to the small business vendors 
to convert to an electronic invoicing system. Our initial analysis has shown that processing ^ invoke 
for payment electronically should reduce workload for DFAS and eventually costs to our subsistence 
program. The estimates of what an electronic invoice costs to process are $10 (down from $65 in the 

Sctw eStimat f’ WhCn Electronic Funds Tra nsfer and the Electronic Invoicing 

Miflion h b ^ impIemem '-‘ d our cost sa vings on a yearly basis are estimated to exceed $5 § 


PSA Finance 


Lead DoD EC/EDI PM: DLA, POC Jeffrey Nienstedt 
(215) 737-3860 
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Transaction Sets 

820 Payment Order/Remittance Advice 823 Lockbox 
850 Purchase Order 
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Status Prototyping 
Deliverables: Software 
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APPENDIX C - DOD TRANSPORTATION 

(POC USTRANSCOM TCJ4-LT) 


1.0 Background 

?fefol??^v When Assistant Deputy Under Secretary of Defense - Transportation Policy 
ADUSD(TP), conceived the Defense Transportation EDI (DTEDI) program, the Defense transportation 
community has straggled to sustain initial development efforts. Often using minimal resources it has 
had some success in implementing EDI capability in three areas - transportation rates, government bills 
oi lading (GBLs), and earner invoices. As a means of more efficiently advancing those efforts the 

transportation community established the DTEDI committee to guide it through the initial areas 
development into a long-term EDI fielding and maintenance effort. 

5™??’ ^^raffic Mana § ement Command (MTMC) fielded its CONUS Freight Management 
(CrM) system. The CFM system receives electronically formatted standard tenders containing freight 
rates from commercial earners. Defense shipping activities access CFMs rate file to assist in mode 
selection and determining the cost of a shipment prior to a move. MTMC has now qualified more than 
1UU commercial earners for submitting standard tenders electronically to the CFM. 

Complementing MTMCs CFM are the Services and DLAs electronic GBL project and the DFAS-IN 
Defense Transportation Payment System (DTRS) which is developed to receive and process costed 
GBEs and earner invoices electronically. DFAS-IN has made its EDI capability known to the carrier 
industry and sought to expand its use between DTRS and carrier systems. DFAS-IN implemented its 
electronic invoice capabihty in 1994 and currently has the capability to receive electronic invoices from 
more than _>0 commercial earners. 


In a May 1994 memorandum to the Secretaries of the Military Departments and Directors of Defense 
agencies the Deputy Secretary of Defense - Logistics, directed all DOD Components to make maximum 
use of EDI m all business related transactions. As a result the Defense transportation community is 
exchanging 'bills of lading, invoices, rate tenders, and shipment status messages electronically amon* its 
members and commercial industry. Completing the implementation of EDI into those processes and* 
accelerating its expansion to new areas has now become a primary objective of the Defense 
transportation community. 

1995 memo ^ ndum ’ ^Deputy Under Secretary of Defense - Logistics, designated the 
Command (USTRANSCOM) as lead agent for the DTEDI program. As a 
result, USTTxi^SCOM developed a plan that presented a strategy for managing the program That 
strategy calls for USTRANSCOM to develop a comprehensive implementation plan thaf fosters further ' 
development and expansion of the DTEDI program. Since that time, USTRANSCOM has undertaken a 
senes of actions that will enable the Defense transportation community to improve its program 
management capabilities, continue expanding its EDI efforts, and accelerate the development of new 
initiatives. The Defense Transportation Electronic Data Interchange Program Implementation Plan 
May 1996 prescribes an aggressive program to accelerate the pace of EDI implementation in support of 
transportation. This plan is aimed at focusing energy, attention and resources toward expanding EDI 
uses m support of DOD transportation business information exchanges. It identifies basic requirements 
for the use of EDI in support of DOD transportation in addition to detailing the current EDI initiatives It 
further describes in some detail those actions regarding the freight transportation program and proposed 
plans and schedules tor implementing them. The current plan only addresses implementing EDI in the 

ttcto ^McSSl7 ar ^F5 rlat, ?i? and the eleven Passes that support it. During FY96 
USTRANSCOM will desenbe DODs EDI programs for passenger and personal property transportation. 

Along with its successes the Defense transportation community has gained valuable experience during 
the development and fielding of these EDI initiatives. The DTEDI committee has been particularly 
instrumental in resolving problems. Some of the DOD Transportation EDI initiatives have matured past 
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the development phase and are entering the life-cycle phase. The DTEDI committee, with its established 
administrative and technical procedures, provides a strong basis for addressing the issues associated with 
the life-cycle maintenance process. 

2.0 Basic Requirements 

^ ky developing EDI processes and managing their coordination through 
dte DTEDI committee, the Defense transportation community has laid the groundwork for expanding 
EDI applications to all facets of transportation and adapting rapidly changing business and technological 
environments. 5 

The DOD is seeking to enhance several transportation and logistics processes using EDI. Specifically 
the Defense transportation community is exchanging bills of lading, invoices, rate tenders, and shipment 
status messages electronically among its members and commercial industry. Introducing EDI technology 
into those processes directly benefits several DOD logistics programs such as the Total Asset Visibility 
(TAV) and InTransit Visibility (ITV) integration programs. Completing the implementation of EDI into 
those processes and accelerating its expansion to new areas has now become a primary objective of the 
Defense transportation co mmuni ty. 

The Defense transportation community has implemented the EDI GBL Billing and Payment and Carrier 
Rate Submission Projects using Sprints EDI VAN services procured under a GSA contract Those 
services are now being provided by Sprint under provisions of a Federal Telecommunication Service 
2000 contract. USTRANSCOM is evaluating four communications alternatives to provide its loner-term 
and interim EDI telecommunications requirements. The DTEDI program requires an EDI VAN for DOD 
activities to exchange data electronically with their commercial trading partners and with their DOD 
trading partners that do not have access to a military data network (such as DISN). Transportation 
activities should continue to use DISN when it is available for exchanging EDI data within DOD but 
they also require access to a commercial EDI VAN. That VAN must have the capacity to satisfy Defense 
transportation s value-added telecommunications service requirements and its estimated volume of data 
(A list of value-added telecommunications services is described in Chapter 6 of Defense Transportation 
Electronic Data Interchange Program Implementation Plan). The four telecommunications alternatives 
under consideration by the DTEDI are: 

1 . Use the Federal Acquisition Computer Network (FACNET). 

2. Use the EDI VAN services available under the Federal Telecommunication Services (FTS) 9000 
contract. 

3. Allow each transportation activity or Military Service and Defense agenev to contract separated for 

EDI VAN services. ' 

4. Use the EDI VAN service capabilities of the GTN contractor. 

The alternative that best satisfies the Defense transportation communitys requirements has not been 
selected. The DTEDI needs to select the least-risk EDI telecommunications alternative. Defense 
transportation s bill of lading electronic payment program currently operates in a production 
environment so it cannot implement an EDI telecommunications strategy that is unproven. The DTEDI 
program needs to embrace both an interim and long-term strategy that offers the lowest risk to its current 
EDI initiatives. 

3.0 Analysis and Considerations 

Analysis: The Defense Transportation Community with USTRANSCOM at the lead has determined that 
EDI will be used as a vehicle for transportation modernization. 

Considerations: EDI Implementation Conventions must be developed and maintained to meet the 
business requirements of all trading parties to the exchange. Business processes, rules, and practices 
must be understood with Automated Information Systems synchronized to version and release in a 
thoroughly integrated structure to gain real advantage from the EDI technology. Ad Hoc development 
efforts usually prove of little value and lead to more frustration and cost to update than do corporate 
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actions. Configuration management of software and implementation conventions is ofutmost 
importance to rapid and effective utilization of EDI when meeting daily business needs. 


Attachment 1 to Appendix C 

Transportation Projects Supported by the DOD Electronic Commerce Office 

The following Transportation EC and EDI project is being funded, at least partially, and supported by 
DUSD(AR/EC), the DOD Electronic Commerce Office. Attachment 1 to this appendix contains a short 
description of it and also identifies which XI 2 transaction sets are being used. 


PSA 

Project ID 

Project Title 

Transportation 

95DLA017 

ASN Consist Initiative 


This project description was not on the diskette. 
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APPENDIX D - DOD MEDICAL LOGISTICS 


1.0 Background 

Medical logistics is a tetion widiin the Military Health Services System (MHSS), a worldwide 
organization composed of the health resources of DOD, Army, Navy and Air Force The infZ,ati n n 
required for MHSS covers a diverse range of peacetime and 4S=^re* .adudin^comSed and 
C3re ’ P reven J ve medicine, research, and logistics. Medical logistics supports the MHSS health 
care delivery mission by furnishing matenel, equipment facilities, services and information resources 

SSf 0g P S^es 4 r“ Ume “* Wanime ' ^ cmie0t aut0mated systems 

* S 61 ?^!^ 006 !! 1112 y d -P istrib . u 5. on ( CPD ) operates at one Army, 19 Navy and four Air Force 
toet Sd offiS“ppUes meS ^ S) ““ SUPPOm tatra - faciIit >' distribu 'ion of medical supplies. 

* (MEDLOG) operates at 89 Air Force peacetime and contingency 
hospitals. MEDLOG provides comprehensive and integrated Medical Retail Supply support 
extensive quality assurance, assemblage management capabilities, medical equipment 

^Sf ge iff ? “u Bl0 A medical Maintenance capability. MEDLOG also support the administration 
hIc ^ Agreements contracts. Mobile MEDLOG operates with Air Transportable 

Hospitals (29) to support wartime/contingency medical supply. Mobile MEDLOG provides the 
same capability as MEDLOG but operates on a laptop personal computer. P 

* Mana § ement Information System-Medical Logistics 
(T ^°5u- MEDL ° G) 0per 7 tes at 48 P eac ctime hospitals and 140 field units to order manage 
-“ ute ec J UI Pment and medical supplies for contingency and peacetime requirements. * ’ 
TAMMIS provides the Army with a single medical supply system supporting peacetime and 
wartime/contingency at all active Army, Reserve, and National Guard medical supply options. 

• Army Medical Department Property Accounting System (AMEDDPAS) operates at 48 peacetime 
hospitals and provides comprehensive equipment management including planning, funds tracking 
property accounting, equipment maintenance, central asset visibility and excess redistribution. 

• Navy: Medical Inventory Control System (MICS) operates at 17 Naw hospitals to provide an 
bT thT^wTofkTund^' 1 fmanC,al accoumin S s y stem for medical treatment facilities supported 

• Micro Medical Inventory Control System (Micro-MICS) operates at 35 Naw medical and dental 

Micro-MICS is the logistics system for hospital ships and 
provide joint service interoperability support during wartime and in contingency operations. 

* Biomedical and Facilities System (BIOFACS), a commercial off-the-shelf system, operates at 55 

Navy medical and dental treatment facilities to provide support for property accounting and 
equipment management. 5 

• Property Management and Budgeting System (PMBS) operates at over 80 Naw medical and 
dental treatment facilities to provide automate support for property management and accounting. 

’ requiremems° CUremem SySKm (APS) ° perates “ four Navy Hos P itals to support small purchase 

^°f S ?T dard . Supp0n ( DMLSS > Program is responsible for defining and 
implementing an efficient medical logistics support environment for health care operations in peacetime 
military operations other than war, and wartime. The program is composed of two major component 
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The program objectives identified for the MLFPIP and DMLSS AIS are: 

• nnntT'Tr standard data based systems to automate all health care logistics functions in 

DOD Medical Treatment Facilities (MTFs) worldwide. g s runctions m 

’ S ita ^ e sharing of common data within the MLFPIP and DMLSS environments bv 
DO^eK^ScTsynOT.' 13 "^ *** e ' ementS ^ the m and ^oughout the 

• Improve accuracy and response time for Medical Logistics. 

• Incorporate electronic commerce technology. 

• Move toward a paperless transaction work environment. 

• Develop more efficient contract/payment procedures. 

The DMLSS Program Telecommunications P/cwdated ADril 1 1994 the Uo^i^ni r„ ■ *• r- 

SgE'—"*' to— to — toJkS£— '£ DOO Suu 

2.0 Basic Requirements 

• «SiS! L °? istics "“X hav " the requirement to issue purchase orders against vendor electronic 
Inftet^cmre!* ^ ° §S *** purchase orders ** exchanged using the DOD EC and EDI 

• Medical Logistics intends to use industry-specific X12 standards and conventions that are in 
compliance with the DISA Center for Standards X12 IC development process 

• hsSK? tha f. M * dicaI L °§ istics w ants to implement the prime vendor concept which utilizes 
direct connections to vendors outside of the DOD EC and EDI Infrastructure P ’ ““ * 

may require' modification nfihe DC© EC and S EDI I?ifi0^cm l re PlO ' Vment moblh2ation 1)131 

Mthm^e^any^conuoUed^hesH'^e Medcld Vreatm^ isconsid st ^ )or j? r ^’ „ 
may he a medtca, center, hospitai, clinic ,n„ in-patS^^^^S 
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unit, or independent unit (e.g.. Naval Dental Centers [NDCs]). DLA DPSC is a DOD wholesale 
management function at a fixed location (Philadelphia, PA). 

The second environment is field medical operations. Traditionally, this environment is considered field 
operations in which mobile medical units have been deployed to a location away from the fixed MTF 
and must provide the same level of logistics support. Field operations shall require DMLSS AIS 
equipment to operate effectively in a variety of enviro nm ental conditions. 

3.0 Analysis and Considerations 

The Preliminary Functional Economic Analysis for medical logistics identified deficiencies in decision 
support, communication, and information processing at all levels of the Military Health Services System 
in 1 992. The existing information systems relied upon a combination of manual and automated 
procedures for the compilation and transmittal of information. Information processing procedures differ 
between the three services and among information systems within each service. Each service operates 
and maintains its own hospital logistics system(s). K 

The Medical Logistics Functional Process Improvement Program (MLFPIP) identified alternatives and a 
strategy to identify and implement improvements that significantly reduce costs and improve medical 
logistics support. The Medical Logistics FEA examined three alternatives and chose the option with the 
highest return on investment The alternative chosen included the following options: 

• DPSC award centralized prime vendor contracts with commercial medical distributors 

• DPSC award centralized contracts with all manufactures of medical supplies for their entire 

product lines. These items would be distributed by prime vendor distributors direct to the hospital 
level. * 

• EDI will be used to order items, process invoices and provide electronic funds transfer 

• Items stocked at DLA depots will be reduced to levels necessary for wartime/contingencv 
responses 

• MLFPIP and DMLSS will be deployed to the largest MTFs first to achieve earliest payback 

• DPSC will be able to perform leverage buying of medical supplies to achieve the best prices based 
on consumption history 

3.1 DMLSS 

An integrated Defense Medical Logistics Standard Support (DMLSS) Automated Information System 
(MS) was identified as a method to standardize business practices for all MHSS logistics organizations 
DMLSS AIS, after implementation, will replace forms; perform on-line product research; report 
real-time status of orders and fund balances; and serve as a crucial communication link between medical 
logistics personnel and customers, vendors, finance, contracting, procurement, maintenance support 
activities and other agencies, pie DMLSS AIS development will be integrated with Business Process 
Reengineering initiatives that include bar code technology, contracting warrants, dedicated trucks, 
Forward Customer support (FCS), inventory management to point of consumption, mechanized material 
handling systems, Medical Express, Prime Vendor, and TotalPackage Fielding (TPF). 

DMLSS is Planned for deployment to nearly 350 large, medium and small medical treatment facilities 
(MTFs), Army MEDLOG battalions, field units. Navy hospital ships, Air Force air transportable 
hospital, and Navy dental clinics. 

The DMLSS AIS is anticipated to: 

• Reduce pipeline time from when the need is identified to need satisfied 

• Reduce on- hand inventories 

• Reduce utility and maintenance costs 

• Reduce number of items destroyed because the credit or replacement return date has expired 

• Improve reutilization of excess serviceable items in the MTF 

R e duce AIS and non-AJS consumables through use of electronic forms, reports, and documents 

• Reduce or eliminate late vendor payments through automation 
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DMLSS will be based on four subsystems that will support its users: 


1. Facility management 

2. Equipment and technology management 

3. Materiel management 

4. Customer support 

Medical logistics is linking the shutdown of legacy systems to both availability of the DMLSS AIS 
software and achievement of MAISRC milestones. The final increment of DMLSS AIS is scheduled to 
be available by 1998. 

3.2 EDI and Just-in-Time (JIT) 

EDI is planned to provide savings in administration and provide JIT implementation of inventory 
management. JIT inventory management can provide savings from reduced inventories and associated 
costs, increased flexibility to allow relatively quick changes in medical emphasis and fostering 
competitive commercial practices to use depot operations when advantageous. The DMLSS EDI is also 
planned to allow MTFs to interact with the commercial medical market and facilitate the use of local and 
decentralized Blanket Purchase Agreements. 

One item of concern to Medical Logistics is that it requires 24-hour receipt acknowledgment of 
transactions sent.They require vendors to receive Medical Logistic transactions within 24-hours. 
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APPENDIX E - DOD PROCUREMENT 


1.0 Background 

The military departments, defense agencies, and their components have developed processes and 
business practices, including approximately 76 unique Automated Information Systems (AISs), to 
perform their procurement missions. One AIS, MOCAS, also supports the financial communitv’s 
payments function. y 

Although the processes and business practices at non-automated procurement activities operate within 
the same general framework, they are not standardized. As a result, information transfer among 
contracting activities is often a manual process requiring multiple re-keying of data that increases the 
probability of errors and accurate DoD corporate procurement information is not readily accessible. 
Generally, such manual processes are labor intensive, costly, and less efficient than automated processes. 

2.0 Basic Requirements 

The Director, Defense Procurement, recognizing the inefficiencies and costs associated with sus taining 
existing automated and non-automated procurement systems, established the Standard Procurement 
System (SPS) Program. The SPS is an iterative program with capabilities and deployment time phased 
to correspond with user needs and budgets. For EC/EDI purposes, the key elements of the SPS are: 

• a commercial software application that will perform standardized procurement functions, 

• standard procurement data developed in conjunction with DoD Enterprise data standardization 
effort, 

• a shared data warehouse that will permit receipt and distribution of standardized procurement data, 

• and the DoD Defense Information Infrastructure(DII). 

System acquisition, deployment, and support are managed by the Defense Logistics Agency's Defense 
Procurement GIM Systems Center (DPCSC). 

\ 

2.1 Standard Procurement System Objective 

The SPS’s primary objective is improved procurement support for the Warfighter. To achieve that 
objective, the SPS application software will be deployed to each contracting activitv and access provided 
to the shared data warehouse and the DII. The linking of standard software, standard data, the shared 
data warehouse and the DII will provide each contracting activity with an improved, standardized 
EC/EDI capability, facilitate the procurement process and thereby improve end user support. 

2.2 DOD Procurement Electronic Data Interchange (EDI) Vision 

The Director of Defense Procurement envisions an EDI capability for SPS that allows a complete 
exchange of procurement information with DoD contractors, among DoD's procurement activities, and 
across DoD functional areas, in a paperless environment. To accomplish that vision, the SPS application 
software is required to receive or generate information in ANSI X-12 format, populate the DoD 
procurement data base mapping to DoD standard data definitions, and operate within the DII 
communication parameters. Consequently, SPS will operate in any EC/EDI environment that is 
consistent with the DoD established criteria. 

3.0 Analysis and Considerations 

The following paragraphs describe specific issues related to EDI standards and legacy svstems related to 
the SPS program and a short summary of other projects that are underway in the DOD Procurement 
community. 

3.1 EDI Standards 
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SPS will use the national EDI standard, ANSI ASC XI 2, for its initial capabilities. Support for the 
UN/EDIFACT international standard will be added when that standard has been updated to include the 
required functionality for DOD procurement activity. 

Initial X12 transaction set support will occur at Version 3050, using Federal implementation 
conventions (ICs). Federal ICs will be produced for X12 Versions 3060 and 3070 which will be 
incorporated into SPS as necessary to support DOD procurement activities and trading partners. 

Initial UN/EDIFACT support is not expected until Spring 1998 with the release of UN/EDIFACT 
Version D.98A. Pilot programs with limited objectives may be executed earlier to gain experience with 
the UN/EDIFACT syntax. 

3.1.1 X12 Transaction Sets 

Initially, the SPS application software will generate or receive the following ANSI ASC X12 tr ansac tion 
sets and will interface with transaction set 838, Trading Partner Profile: 

• 824 - Application Advice 

• 836 - Procurement Notices 

• 840 - Request for Quotation 

• 843 - Response to Request for Quotation 

• 850 - Purchase Order 

• 855 - Purchase Order Acknowledgment 

• 860 - Purchase Order Change Request -Buyer Initiated 

• 864 - Text Message 

• 865 - Purchase Order Change Acknowledgment/Request -Seller Initiated 
Other X12 transaction sets being considered for SPS include: 

• 503 - Pricing History 

• 848 - Material Safety Data Sheet 

• 869 - Order Status Inquiry 

• 870 - Order Status Report 

Until its functions are incorporated into SPS, the Pricing Workbench will provide support for: 

• 251 - Pricing Support 

• 805 - Contract Pricing Proposal 

3.1.2 UN/EDIFACT 

The DPCSC is participating with the ASC X12 Purchasing Subcommittee, the Pan American EDIFACT 
Board, and the UN/EDIFACT Joint Rapporteurs' Team to accomplish migration of functionality from 
XI 2 to UN/EDIFACT. The UN/EDIFACT messages expected to be initially generated or received by 
SPS are: 

• REQOTE - Request for Quote 

• QUOTES - Quote 

• ORDERS - Purchase Order 

• ORDRSP - Purchase Order Response 

• ORDCHG - Purchase Order Change Request 

• PRIHIS - Price History 

• OSTENQ - Order Status Enquiry 

• OSTRPT - Order Status Report 

*♦ SAFHAZ - Safety and Hazard Data 
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APERAK - Application Error and Acknowledgment 

3.2 Legacy Systems 

The functions performed by some legacy automated systems must be sustained until a fully functional 
SPS is deployed. The FY 95 and FY 96 reports required by Section 381 of the National Defense 
Authorization Act for Fiscal Year 1995 have been submitted to the Congress. 

Many procurement AISs presently possess an EDI capability using older versions of the X12 standard or 
using proprietary standards. DPCSC has supported several projects to convert legacy system capabilities 
to the Federal 3050 IC, attaining a "single face to industry" across multiple applications. Upon 
completion, each of these AISs will transmit and receive data via EDI with the same appearance as SPS 
This "single face" will allow replacement of legacy systems by SPS without disruption of EDI activity 
with DOD's trading partners. 

Legacy systems converting to the Federal 3050 IC from earlier Federal IC's are: 

APADE 

DPACS 

ITIMP 

DPCSC is also providing an initial EDI capability using the Federal 3050 IC to a number of procurement 
AISs. This effort supports the DoD Comptroller’s interests in obtaining standardized, electronically 
transmitted, payment information for major weapon systems contracts. These include: 

AMAS 

AMIS 

PADDS 

MOCAS 

3.3 Other Procurement Projects 

Other DOD Procurement EC and EDI projects are being funded, at least partially, and supported by 
DUSD(AR/EC), the DOD Electronic Commerce Office. Attachment 1 to this appendix contains a short 
description of each of them and also identifies which X12 transaction sets are being used. 


PSA 

Project ID 

Project Title 

Procurement 

95AFXXX 

Bar Coding ~ 

Procurement 

95 ARM 001 

Acquisition Support Program 

Procurement 

95DCA 001 

Electronic Pricing 

Procurement 

95DCO 001 

EC/EDI Within DECCO 

Procurement 

95DLA 009 

Subsistence Multi-Line Invoicing 

Procurement 

95UMC 005 

Blount Island EDI 

Procurement/ Acquisition 

95NAV 002 

Contractor Performance Reporting 

Procurement/ Contract Management 

95DLA 001 

Progress Payment Request 

Procurement/ Contract Management 

95DLA 003 

Plant Clearance 

Procurement/ Contract Management 

95NAV 006 

Contractor Cost Data Reporting 


Attachment 1 to Appendix E 


of 13 


11/13/96 8:21 



Procurement Projects Supported by the DOD Electronic Commerce Office 


PROJECT 95AFXXX 

SUPPLY CHAIN MANAGEMENT & BAR CODE INTEGRATION 
BUSINESS PROCESS RE-ENGINEERING EC/EDI 

The existing process to order, track, and to pay for communication and computer equipment within the 
Air Force requires the use of numerous paper forms and other documents. The process starts with a user 
requesting systems that will enable the user to perform their job better through a C4 Systems 
Requirement Document (CSRD). The request is reviewed and, if approved by the AF Communication 
Squadron, turns into a request for purchase (AF Form 9). Once approved, the paper Form 9 travels 
through different offices for approval, review, and signatures with it ending up at Defense Finance and 
Accounting Service (DFAS) for commitment of funds. DFAS sends the paper Form 9 to the base 
procurement office to be manually entered into the base contracting accounting system (BCAS). The 
Procurement Office sends out a paper purchase order to the selected vendor. Paper copies of the 
purchase order are also sent to requesting organizations and to DFAS for obligation of funds. The 
vendor delivers the order to the Base Warehouse which, in turn, must notify the Communication 
Squadron and the requesting organizations through paper documents. Once the receiving organization 
accepts the equipment, the Communication Squadron sends DFAS paper documents for vendor payment 
and expenditure of funds. 

The current paper system for ordering and tracking the procurement of communication and computer 
equipment is prone to errors, lost paper work, and re-keying of data into various proprietary systems. 
This scenario restricts the ability of organizations, in a timely manner, from tracking, payment, and 
accounting of equipment. By using Activity Based Costing it was found that a typical AF Form 9 cost 
over $2,000 to process. In addition, reviews of Prompt Payment documents found that hundreds of 
thousands of dollars were spent on interest penalties. 

Electronic Data Interchange and Supply Chain Management (SCM) will eliminate the cumbersome flow 
of paper requisitions, purchase orders, invoices, shipping/receiving forms, technical specifications, and 
other documents for the acquisition of Automated Data Processing Equipment (ADPE) by replacing 
paper forms with electronic equivalents. In addition, SCM will provide a seamless, event-driven process 
that will save time and money. The user organization, DFAS, and Procurement can improve the 
accuracy and flow of information, which is essential to these organizations, by using the 5 1 1 
(Requisition) transaction set to replace the Form 9 and the General Accounting Office (GAO) approved 
electronic signature/security system to provide for security and signatures. Using the AF MADES II/EDI 
system. Procurement will be able to send accurate and reliable purchase information in the form of the 
850 (Purchase Order) to the Trading Parmer (vendor). The Trading Partner will send an Advanced 
Shipping Notice (ASN ), (transaction set 856 Ship Notice Manifest) to the Base Warehouse, thus 
allo wing the Warehouse to promptly notify all interested parties of the date and time that the ordered 
equipment will be arriving. The ship notice manifest contains bar code information and related purchase 
order data which corresponds with the item ordered. The Warehouse scans the Bill-of-Lading off the 
packing slip which is then compared to the original 850 purchase order. An American National 
Standards Institute (ANSI) X12 861R, Receiving Certificate, sends receiving information to 
Procurement and DFAS which can update the Air Force inventory tracking system (Integrated Product 
Management System (IPMS). After completion of end user acceptance, an ANSI X12 861 A, Advice 
Acceptance Certificate, is sent to DFAS so payment can be made to the Trading Parmer. This process 
helps alleviate interest penalties and other costs. The use of the ANSI X12 854 will be used to notify the 
Trading Parmer if a delivery discrepancy occurs. The ANSI X12 997, Functional Acknowledgment, is 
required for all transactions. The collection of the 997 will be used to create audit trails. The project will 
include a shared database assembled using EDI standards and other Commercial Off The Shelf (COTS) 

This-project team consists of key personnel from Procurement, DFAS, Air Force Audit Agency 
AFC4A, and inputs from the GAO. ° ’ 
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PSA: Procurement '• ' 

Lead DoD EC/EDI PM: Air Force, POC LT Matthew K. Miller 
(3 1 0) 363-2080 DSN 833-2080 

Technical Lead: Mr. Steven J. Lucks 
(3 10) 363-1 155 DSN 833-1 155 
Transaction Sets: 

• 511 Requisition 

• 850 Purchase Order (MADES II ver. 3010) 

• 854 Shipment Delivery Discrepancy 

• 856 Ship Notice/Manifest 

• 861 Acceptance Certificate/Receiving Advice 

• 997 Functional Acknowledgment 

Status: Prototype (proof of concept) 

Hardware and software upgrades. Contract Labor, component upgrades (HW/SW under S15K), and 


PROJECT 95ARM 001 

ACQUISITION SUPPORT PROGRAM (ASP) 
PREVIOUSLY IDENTIFIED AS 95NAV017 
JOINT ACQUISITION MANAGEMENT SYSTEM (JAMS) 


In keeping with the facilities of the EDI technology, the ASP project is being developed to operate 
independently from existing application systems in order that the prototype can be exported to other 
sites. The project is led by the Simulation, Training and Instrumentation Command (STRICOMV the Air 
Force partner is Eglin Air Force Base and the Navy partner is the Naval Air Warfare Center-Trainina 
Systems Division (NAWCTSD) and a second Army partner is the Army Missile Command (MICOM) 
We will also work with the Defense Information Systems Agency (DISA), the Defense, Finance and 
Accounting Service (DFAS), and Defense Contract Management Command (DSMC) on this project 
The EDI project is being managed under the Acquisition Support Program (ASP) umbrella, as this is the 
application in use by STRICOM and NAWCTSD and under evaluation by Eglin Air Force Base ASP is 
a modular toolset which provides the following functionality: 


• Integrated Management Information System (IMIS) - An integrated svstem for project 
management and tracking. 

• Procurement Information Systems Management/Acquisition Professional (ProMIS/AcqPro) - 

Supports acquisition package development with ready access to an acquisition librarv including 
key acquisition regulations. ' * 

• Proposal Evaluation Tool (PET) - An automated multi-user source selection toll designed for a 
paperless environment. 

• Automated CDRL and Tracking System (ACTS) - An automated tool supporting the development 
and tracking of Contact Data Requirements List (form DD 1432) 

• Acquisition Tracking System (AcqTrack) - Provides members of program/project offices access to 
current information regarding project status. 

The purpose of the svstems acquisition EDI initiative is to incorporate EDI transactions for the entire 
project life cycle beginning with the RFP. 


PSA Procurement 

Lead DoD EC/EDI PM: Army, POC Donna Felix 
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(407) 384-3799 

Transaction Sets: 

• 196 - Contractor Cost Data Reporting 

• 850 - Delivery Order 

• 8 1 0 - Invoice 

855 - Delivery Order Acknowledgment 

• 839 - Project Cost Reporting 

• 860 - Delivery Order Change 

• 840 - Request For Proposal 

• 865 - Delivery Order Change 

• 843 - Response To Request For Proposal Acknowledgment. 

This project will prototype 3050 federal implementation conventions for those transaction sets marked 
with an asterisk above. In order to achieve the extended enterprise with industry using EDI transactions, 
the project will include some transactions not funded by OSD at STRICOM which will include: 
Contractor Cost Data Reporting (196), Project Schedule Reporting (806), Project Cost Reporting (839), 
and Specifications/Technical Information (841). STRICOM and its partners will coordinate with the 
designated OSD lead for these transactions. 

Status: Prototype 

The Air Force and Navy are currently evaluating proposed prototype weapons/training programs. The 
following Army prototypes and industry trading partners are as follows; 

MICOM ("Weapons Systems) Trading Partner 
Patriot Missile System Loral-Vought, Raytheon 

STRICOM Trading Partner 

Advanced Distributed Simulation Technology (ADST) Lockheed Martin 
Test Support Network (TSN) GTE 

Fire Support Combined Arms Tactical Trainer (FSCAT) Hughes 
Battle Lab Reconfigurable Simulation Initiative Hughes 


PROJECT 95DCA 001 
ELECTRONIC PRICING 

Manufacturers frequently change the packaging of specific grocery items. In addition, promotions, sales, 
and coupon usage routinely alter the price of many items, Thus, prior to electronic pricing the Defense 
Commissary Agency (DECA) devoted significant resources to item pricing and maintenance activities, 
primarily at its regional offices. DECA processed more than 1 . 1 million price quote sheets for item 
pricing each year. Under the manual system, each of the six regions would individually receive the price 
quotes from manufacturers and brokers and key-enter them into their regional DECA Integrated 
Business System to be electronically distributed to all commissary stores located within their regions. 

The electronic pricing process eliminated the need for pricing at the six different regional locations. 
Manufacturers and brokers transmit price changes to DECA Headquarters using the 879 (Price Change) 
transaction set. Prices are validated electronically and non-matching items are returned to the vendor = 
using the 824 (Application Advice) transaction set. This system has improved the efficiency and 
effectiveness of maintaining the catalog master file and has significantly reduced pricing errors between 
DECA and commercial manufacturers. This process eliminated the need to perform price and item 
maintenance which had been performed at multiple DECA locations for an annual cost avoidance of 
5270,000. 

DEC-A strongly encourages all business partners to send their prices electronically. Trading partners 
must be able to electronically send prices to DECA prior to DECA administering the Resale Ordering 
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Agreement (ROA) and allowing them the option of using the Electronic Funds Transfer (EFT) process. 

DECA also offers vendors who send prices electronically the opportunity to use the Delivery Ticket 
Invoice (DTI) payment method using the delivery ticket as a basis for payment, eliminating the invoice 
from the bill-paying process. No documentation is required for payment, eliminating 1 1 associated 
processing and mailing costs (or EDI costs for the electronic invoice) including the costly reconciliation 
process for both DeC A and the manufacturer. 

The electronic pricing will eliminate the need for manual data entry of monthly prices for over 200,000 
resale items at six regional offices. There are many related cost avoidances that are gained by using this 
method of pricing versus the manual pricing that cannot be directly accounted for in the total ordering, 
receiving and selling process of DeCA's resale items. 

PSA: Procurement 

Lfead DoD EC/EDI PM: Defense Commissary Agency, 

POC Tom Hackett 
(804)734-8351 

Transaction Sets: 

• 824 Application Advice 

• 889 Promotion Announcement 

• 879 Price Change 

• 997 Acknowledgment 

• 888 Item Maintenance 

Status: Deployment 

Software Development and DeCA wide 


. PROJECT 95DCO 001 

EC/EDI WITHIN DECCO 

Currently, the Defense Information Technology Contracting Office (DITCO) has four functional areas: 
Pre-Solicitation, Solicitation & Award, Contract Administration, and Close-Out. DITCO performs the 
majority of procurements for telecommunications services in DoD and Federal Information Resource 
Management Regulation (FIRMR) resources. These procurements are done using manual methods and 
the Defense Electronic Bulletin Board Service (DABBS). A large number of these procurements of 
circuits are time-sensitive requiring the fastest possible processing and contractor response time 
available. 

Under the DITCO Electronic Data Interchange (EDI) project, application interfaces will be developed to 
integrate EDI capabilities within DITCOs existing Customer/Vendor Interface (CVI) and network 
infrastructure. EDI will facilitate an expansion of the commercial industrial base supporting DITCO, 
provide greater and faster competition, reduce data entry time and costs, enhance data integrity, and 
provide greater access to common shared databases of contract and financial data supporting the 
telecommunications procurements. 

The improvements will be in the areas of one time data entry, and improved financial and accounting 
services. The one time data entry will improve the effectiveness and efficiency of DITCOs operation by 
reducing the opportunity for data entry errors, eliminating duplicate entries and enhancing the integrity 
of the stored data. Our financial and accounting services will be enhanced by the implementation of 
Electronic Fund Transfer with both our customers and suppliers. This conversion will enhance the 
accuracy of our financial record while reducing the required labor hours. 

PSA: Procurement 
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Lead DoD EC/EDI PM: Defense Commercial Communication Office (DCCO), 
POC Lisa Buckmann (6 1 8) 256-9587 
Transaction Sets: 


• 81 1 Consolidated Service Invoice 

• 850 Award Document 

• 820 Payment Order/Remittance Advice 

• 855 Acceptance 

• 824 Application Advice 

• 860 Modification 

• 836 Procurement Notices 

• 864 Test Message 

• 838 Trading Partners Profile 

• 865 Response to Mod & Changes 

• 840 Solicitations 

• 869 Order Status Inquiry 

• 843 Contractor Responses 

• 870 Order Status Report 

• 997 Acknowledgment 

Status: Prototype 

Security Risk Assessment, Data Modeling/ Interface with 840 and 843 Transaction Sets 
Modeling/Interface with 810, 820, 850, and 856 Transaction Sets, Training and Supplies 


PROJECT 95DLA 009 
SUBSISTENCE MULTI-LINE INVOICING 

Project: , 

To understand the current project it is best to start with a little history of Electronic Invoicing in 
Subsistence. The original Subsistence Electronic Invoice process was developed around Brand Names. 
This logic involved a single delivery per invoice. The original testing of the project was with Proctor and 
Gamble (P&G) but switched to Del Monte when P&G was unable to provide Contract Line Item 
Numbers (CLIN) back to Subsistence. These CLINs were needed to produce the results of line item 
accounting that the Government financial community wanted. The project was in the middle of testing 
with Del Monte when funds were exhausted. It was discovered during this time frame that P&G was not 
the exception but rather the rule in not being able to provide CLINs back to DPSC. Most of the food 
industry did not keep these numbers in their systems and were unable to provide them when we 
requested. 

Any electronic solution is only as good as the number of documents and partners that are actively using 
the system. Because of our original problems with getting trading partners who could provide CLINs 
back to DPSC, the focus switched to developing a system which did not require vendors to provide 
CLINs back. The recent decision in using a summary invoice for prime vendor alleviates the need for 
this logic because the CLIN count will always be one. In addition, in the development of a distributed 
Electronic Invoice process (fresh fruit and vegetables (FF&V) Business Process Improvement (BPI) 
process, DPSC was able to solve the problem by providing the contract line items numbers back to itself. 

The Subsistence Multi-Line Invoicing project is an enterprise project which adds electronic invoicing 
functionality to the current payment process. The Defense Systems Design Center (DSDC) has been" 
chosen to do the programming for this project because it was the most cost effective solution. The funds 
for this project will be used to fund the project being done by DSDC. 

The current project is the link between the logic and the newer contracting methods of long term 
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contracting It builds on the functionality of the original project and allows the original module to accept 
multiple deliveries on the same invoice. This project is based on the current commodity set-up and 
targets the high volume, labor intensive areas first. 

The programming involves modifications to current systems which allow processing of multiple call 
(delivery) invoices m lieu of the single line processing which was developed for Brand Name In 
addition hinds wiU be used to program links between this process and the data which will be provided 
?■ y p*EF*V BPI system. Once these steps are completed, the process wiU be tested and trading partners 
m the FF&V and Prime Vendor areas will be added. ° ” 

PSA: Procurement 


Lead DoD EC/EDI PM: Defense Logistics Agency, 
POC Jeffrey L. Nienstedt (215) 737-3860 

Transaction Sets: 


• 810 Invoice 

• 805 Award Document 

• 820 Payment Order/Remittance Advice 

• 850 Grocery Products Invoice 


Status Prototype 
Deliverables: 

The deliverables for this system consist of a working Electronic Invoice process for FF&V Prime 
pSvotS* 1 Dep0t St ° Ck 30(1 automation of invoice data input for FF&V trading partners from our 


PROJECT 95UMC 005 
BLOUNT ISLAND EDI 

The primary mission of the Blount Island Command is to plan and coordinate logistical support for the 
Maritime Prepositioning Ships (MPS) program and the land prepositioning program in Norwav. 
Currently, the procurement of supplies and services are accomplished through a manual and paper based 
purchasing system. These requisitions are handed off to the purchasing office and are manually keved 
into the procurement application for processing. This results in long lead time and delays for the ' 
upload/download and maintenance cycles of ships that provide support to contingency forces. 

The objective of this Electronic Commerce/Electronic Data Interchange (EC/EDI) project is to provide 
the Blount Island Command personnel with an information systems which will automate their efforts to 
procure required supplies and services in support of the MPS Program and to manage large, single 
cost-reimbursement contracts. The target system for the procurement of supplies and services is the retail 
version of the Integrated Technical Item Management and Procurement (ITIMP) system. The target 
system for the management of cost-reimbursement contracts is the System for Integrated Contract 
Management (SICM). 

Implementation of the target EC/EDI information system interchange svstem will provide Blount Island 
with a fully automated procurement system. This will reduce lead times', costs, delays, and enable the 
customer to establish a "just in time” inventory capability. In addition, the automated system will 
improve the management of logistics by providing accurate and timely data. 

PSA: Procurement 

Lead DoD EC/EDI PM: Marine Corp, POC Steve Butt (912) 439-5575 
Transaction Sets: < 
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• 840 Solicitation' 

• 843 Quotation 

• 850 Purchase Order 

• ocl c!^ pi ?f nt D ® liver y Discrepancy Information 

• 856 Ship Notice/Mamfest 

• 857 Shipment and Billing Notice 

• 858 Shipment Notice 

• o5i Receiving Advice/ Acceptance Certificate 

• 862 Shipping Schedule 

• 997 Acknowledgment 

Status: Deployment 
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PSA: Procurement 


Lead DoD EC/EDI PM: Navy (NAVSEA), POC 
Mr. Mourad Yacoub (703) 602-1679x154 

Transaction Sets: 


• 839 Project Cost Reporting 

• 806 Project Schedule Reporting 

• 997 Functional Acknowledgment 

Status: Prototype 

Draft 806,839, and Analysis Reports. 

NAVSEA Prototype between AEGIS Destroyer DRPM and Ingalls Shipbuilding initiated January 1995. 
NAVAIR Prototype between V22 PMO & Bell Boeing initiated November 1 995. 

Final versions of all ICs.Testing with NAVSEA/Bath Iron Works scheduled to begin early 1996. 
Continued expansion of Navy implementation. 

Prototypes in AF and Army PMOs. 


PROJECT 95DLA 001 

, PROGRESS PAYMENT REQUEST 

The current system requires manual data-entry as well as manual interface with the Mechanization of 
Contract Administration Services (MOCAS). This process has resulted in the -overrent occ^fona lv 
^ re< ’ uiremc " e of > «* P ">mp. Pay Act, and has had an advene™ on theTc^ 

This project, when implemented, will allow contractors to electronically submit their proeress payment 
requests and Material Receiving Reports (DD 250) to the Administrative Contracting Office and 
eliminate the need for paper processing and data entry. The progress payment aspect of this project is 

^Odavs ro d ?t 0 °4 e da^ d Thf DD^In “ 3 redu f ct ; on of pa ^ ment Processing time, at the activity, from 16 to 
_ a. s to _ to 4 days. The DD _o0 aspect of this program is currently under the functional testing stage. 

PSA: Procurement 


Lead DoD EC/EDI PM: DLA, POC Ron Kunihiro (703) 767-6338 

Transaction Sets: 810 Invoice 
856 Shipment Notice 
997 Acknowledgment 


Status: Deployment 


PROJECT 95DLA 003 
PLANT CLEARANCE AUTOMATED 


II of 13 


11/13/96 8:21 A 


■*t — ' 


• uuj; Jii UL ^5)' 


REUTILIZATION SCREENING (PCARS) 

The current system requires the contractor to mail the list of excess government property to the Plant 
Clearance Office where the information is manually processed. This process is labor intensive and takes 

approximately one to two weeks before an available items appear in the catalog. 

The revised system will enable the contractor to transmit excess government property information 
electronically with all changes to the catalog appearing the next business day. The enhanced system will 
not only save time, money, and labor, it will provide more visibility to the excess property records. 

PSA: Logistics 

Lead DoD EC/EDI PM: DLA, POC Ron Kunihiro (703) 767-6338 
Transaction Sets: 

• 180 Return Authorization 

• 511 Requisition 

• 856 Ship Notice/Manifest 

• 870 Order Status Report 

Status: Deployment 


PROJECT 95NAV 006 

CONTRACTOR COST DATA REPORTING SYSTEM 

The current process requires the paper transmission of a quarterly or semiannual Contractor Cost Data 
Reports (CCDR) and Contractor Performance Reports (CPR) for dozens of large scale production 
contracts that can average over 200 pages in length. Data currently comes in multiple contractor 
determined formats (although there are specific instructions and DoD formats) on a series of multiple 
torms. These reports are often late with the users being required to rekey data into the analysis 
application. This ; rekeying limits time spent on the actual analysis. There is a current backlog of four 
years ofCCDR finals which have not been automated due to lack of funding for the manuafdata entry 
eriort. This scenario restricts the cost analysts to using only portions of the data in a timely manner 
Quality of cost estimates could be substantially improved if all CCDR data were available in an on-line 
database immediately after receipt. 

Electronic Data Interchange (EDI) of contractor cost data will eliminate manual document processing 
and massive data entry efforts while providing for more accurate validation and greater error resolution 
The proposed system will provide a means to standardize reporting formats and data requirements and 
allow analysis of the data to focus on specific areas of interest with out wading through pa^es of 
extraneous data. The overall CCDR reporting process will be streamlined intoa faster, more efficient 
and less costly system. With the emergence of Performance Analyzer (PA) as a standard within DoD 
the effects of EDI are even more pronounced since PA has a built-in interface to the ANSI XP 839 ’ 
Project Cost Reporting" transaction set. 

The ability to share contractor cost information among the various Navy, and eventuallv DOD 
organizations will be significantly enhanced. This program is designed to expand a Navv/OSD initiative 
into an integrated multi-service effort. The project will include a shared database assembled usin^ EDI 
standards. The 196 "Contractor Cost Data Reporting" transaction set was developed bv the ASC XP 
Government Subcommittee and consisted of OUSD(PA&E) and Naval Air Svstems Command 
personnel as well as representatives from private industry. 

Estimates of cost savings indicate that after only two years of direct funding from OUSD (AR-EC) this 
project will begin to show a positive net benefit to the Navy. Beginning in FY 97, net cost benefit is 
expected to average nearly 560,000 per year. 
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PSA: Procurement 

Lead DoD EC/EDI PM: Navy* POC Michael Lamatrice 
(703)604-3611 x2558 

Transaction Sets: 

• 196 Contractor Cost Data Reporting 

• 806 Project Schedule Reporting 

• 839 Project Cost Reporting 

Status: Prototype 

Hardware, Software, and Analysis, Systems, Integration, & Program Management 
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APPENDIX F - DOD LOGISTICS 


1.0 Background 

2.0 Basic Requirements 


cf nd ^ projects are being funded, at least partially, and supported by 
DUSD(AR/EC), the DOD Electronic Commerce Office. Attachment 1 to this appendix contains a short 
description of each of them and also identifies which XI 2 transaction sets are being used. 


PSA 

Project ID 

Project Title 

Logistics 

95DCA 003 

Distribution OCONUS Ordering 

Logistics 

95DLA 008 

Hazardous Material Information System 

Logistics 

95DLA015 

BOSS Hazardous EDI 

Logistics 

95DLA016 

Export Transportation 

Logistics 

95DLA 020 

Automated Bidset Sheets Interface 

Logistics 

95NAV 008 

Non-standard Demand Reporting 

Logistics 

95NAV010 

Non-standard Materiel Request 

Logistics 

95NAV 012 

Materiel Safety Data Sheets “ l 


3.0 Analysis and Considerations 


Attachment 1 to Appendix F 

. Logistics Projects Supported by the DOD Electronic Commerce Office 

PROJECT 95 DCA 003 

DISTRIBUTION OCONUS ORDERING & RESALE SYSTEM 

Defense Commissary Agency (DeC A) identified an opportunity to standardize and improve the 
efficiency and effectiveness of the Military Standard Requisitioning and Issue Procedure (MILSTRIP) 
process. DeCA reengineered the entire process and the resulting product was the "DeC A Overseas ■ 
Ordering and Receiving System^ DOORS). DOORS is an Efficient Consumer Response (ECR) 
application within the DeCA Interim Business system (DIBS). Reduced to its essentials, DOORS is the 
mechanism which DeCA uses to replemsh, either directly or indirectly, stocks of semi-perishable and 
perishable items m overseas commissaries. 

DOORS provides this capability by electronically linking the Overseas Order Points (OOPS) to 
distributors and manufacturers located in the United States through the Order Processing Points (OPPS) 
located m the United States. This electronic linkage of OOPs and OPPs to the distributors and * 

manufacturers who supply the products results in rapid stock replenishment bv direct response to patrons 
demand coupled with the maintenance of much lower inventory levels in overseas areas In developing 
and deploying DOORS, DeCA moved away from the Defense Personnel Support Center (DPSC) as the 
means of providing overseas commissary stock replenishment. 

Making this shift to DOORS is another application of DeCAs basic replenishment philosophy, which 
calls for pulling orders in direct response to patron demand, rather than "pushing" stocks overseas for 
reasons only indirectly related to patron demand. This is one more demonstration of DeCAs 
commitment to offer the very highest quality service to our patrons through an internal initiative 
complemented by cooperation of our industry trading partners. Both our patrons and our industry trading 
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partners are better seized by consistently higher levels of stock availability, fresher products and 
quicker appearance of new items that DOORS makes possible. Additionally, through DOORS DECA 
can deliver a more cost effective benefit: The cost of the third-party support relationship with DPSC is 

C0St r 3&S? of SL2 miUion in OT «head «*<>. and shorter order-ship time 

goo m) ^ y at J ™ p i" ECA t0 mamam a considerably lower dolte “ tav = nt0[ y (by 


On December 21, 1995, DeCA accepted the National Performance Reviews Hammer Award for success 
in reinventing government DOORS was a major player in DECA success toward winning this aS 

PSA: Logistics 


Lead DoD EC/EDI PM: Defense Commissary Agencv 
POC Tom Hackett 
(804) 734-8351 

Transaction Sets: 


856 Advance Ship Notice 997 Acknowledgment 
875 Grocery Product Order 

Status: Demonstration & Prototype 

Software Development and Prototype at Guam commissaries. 


PROJECT 95DLA 008 
HAZARDOUS MATERIAL INFORMATION SHEETS (HMIS) 

Objective: 

H ! Cs t0 P rovide a ™ eth ° d fo , r consistent usage of the ANSI X12.848 Material Safetv Data Sheet 

“ e,sc,ron ' c format in p “ p «“> t -h^ 

Project: 

rt?n^ erS i se f kin . g ? do business with the government electronically should use these ICs in the 
sun of their electronic hazard communication programs and translation systems. The Federal 
Government facilities that are prepared to accept MSDS via EDI will use these specified formats. 

SfewDam ( , FAR) ? q ? a PP arentl y successful offer to submit a Material 

Safety Data Sheets (MSDS) to the solicitor for hazardous material. The Occupational Safetv and Health 

C “ cati0n Standard ( HCS >’ des cribes P die Xwf&SSc 
requirements of MSDS. The enclosed implementation conventions (IC) provide a method for satisfying 
these requirements electronically using the American National Standards Industrv (ANSI) X12 bodv of 

E ^ 0ni , C l nterch , a m § e <&*>• data^maiSor yt±l 

^atTs^de^^din^th^HCS^^ 31 '^ 5 ' ** ICS themseIves ^ not 311 attem Pt to mandate a data set beyond 

i?L™tr d0 ’ howev f- s P ecif y logic structure, data format, and level of detail consistent with the 
Federal Governments information systems. In addition, usage of two of the ICs is predicated uoon the 
adoption of the ANSI S tandard Z400.1, (Material Safety Dam Sheets Preptradon) 1 t£ Federd 

scfsiss 1 bm is oblisated to accept ** msds “’"'p 11 *- mder 

pe purpose of these ICs is to provide a method for consistent usage of the ANSI XP 848 (Material 

St S *! eet t ^ a P sactl °o set - The conventions were developed in conjunction and cooperation with 
the*Join Petroleum Industry Data Exchange (PIDX) and Chemical Industry Data Exchange (CIDX) 
Material Safety Data Sheet Working Group. They are consistent in content and intent with the guidelines 
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ffcnc h ? d by b0th ° f ±e ? i^ 07 F° U P S - Because of the relative lack of standardization of hardcopy 
MbDb formats among the different industries and individual corporations, the Federal Government 
deemed it appropriate to approach an electronic format in partnership with industry to achieve both 
maximum acceptance and usage. 

Trading partners seeking to do business with the government electronically should use these ICs in the 
design of their electronic hazard communication programs and translation 

systems TTie Federal Government facilities that are prepared to accept MSDS via EDI will usethese • 
specified formats. 

PSA Logistics/Environmental Security 

Lead DoD EC/EDI PM: DLA, POC Gene Cogdill (703) 767-2608 
Transaction Set: 848 MSDS 
Status: Demonstration 
Deliverables: 

Reports to evaluate the use of ongoing commercial efforts to standardize the exchange of MSDS bv the 
government. 6 y 


PROJECT 96DLA 015 
BOSS HAZARDOUS EDI 


Initiative: 

The Base Operations Support System (BOSS) Hazardous is a post award contracting system for 
hazardous waste disposal. Processes handled by BOSS include generation of delivery orders and 
modifications to arrange for the pick-up. transportation and disposal of a waste stream, monitoring the 
movement of the waste through shipment manifests, receiving contractor certificates of disposal 
authorizing contractors to invoice for payment and transmitting information to Defense Financial 
Accounting System (DFAS) Center to make disbursements. The current system of accounting for, and 
tracking, hazardous waste disposal is a manual, and labor intensive, paper based system. Hard copy 
delivery orders and modifications are printed, signed, copied, faxed, and mailed to the contractors 
DFAS, our Defense Regional Management Offices (DRMO) and the generators, as required. Hard copy 
manifesting is mailed to the contracting offices. When received the manifest line items are checked • 
against the delivery orders/modifications, and reviewed to insure proper handling and disposal. When 
this verification process has been completed the information is keyed into our database svstem. One to 
many relationships exist between line items and manifests. Each time a waste item is moved until final 
disposal, a manifest is required. One line item may have multiple manifests due to movement of the 
waste storage at alternate facilities, treatment, and disposal. Each manifest line item is entered 
individually into the system. Because of the requirement to re-key data, there is a high likelihood of 


Under an electromc data interchange (EDI) environment, the entire process would be streamlined. 

Ue ivery Orders and modifications will be automated using 850 "Purchase Order", 855 "Purchase Order 
Acknow edgment'|, 860 "Purchase Order Change Request" and 865 "Purchase Order Change 
Acknowledgment transactions sets. In lieu of issuing hard copy delivery orders/mods to the DRMOS 
s 3 ^ 11 ,nterface y f the property accounting system, Defense Automated Information System 
DAISY). The program will be expanded to include the capability for EDI exchange of hazardous waste 
line item detail to our generating activities. This will enable DRMS to streamline and automate the 
certification of manifesting data using EDI. When implemented BOSS Hazardous will automatically 
match interim and final manifest line items with pickup manifest line Items to facilitate accurate and 
nTi y T eP ? rtm iv^ hde u ed ^ Cm§ / [ nan 1 U ? 1 data entr y requirements. Requirements to incorporate Portable 
de^i^de^neH ^ h f n . d ^ eld computer) and barcoding are also being researched and more 
clearly defined. DRMS has identified the requirement for imaging equipment to satisfy legal/litigation 
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issues for third-party/direct environmental clean up. Full integration of BOSS Hazardous data into the 
Single Hazardous Input Program (SHIP) is also planned. Payments will be authorized using evaluated 
receipts settlement procedures and disbursed using electronic funds transfer (EFT). These processes will 
result m a more streamlined business process, paper reduction, and enhanced monitoring capabilities to 
track hazardous waste from cradle to grave. 


Current status. Functional testing of the 850 Transaction Set "Purchase Order" is complete A wai tin g 
o e /n^ eSS ? otlfi cationfrom pilot trading partners to begin production parallel test. Functional testingof 
860 Purchase Order Change Request" is expected to begin mid-January, 1996. Currently finalizing 
streamlined mamfestmg procedures and identifying requirements for evaluated receipts settlement the 
Logistics Management Institute (LMI) is working to ensure DRMS requirements are included in 
implementation conventions that are being developed. We anticipate that the testing of EDI transaction 
sets relating to mamfestmg and evaluated receipts settlement will begin in the May- June 96 time frame. 


PSA Logistics/Environmental Security 

Lead DoD EC/EDI PM: DLA, POC Sherrv Underwood 

(616)961-7229 

Transaction Sets: 

810 Invoice 
820 Remittance 

860 Purchase Order Change 
850 Delivery Order 

861 Material Receipt 

855 Acknowledgment 

863 Certification of Disposal 

856 Manifest 

865 Acknowledgment 


Status Demonstration 
Deliverables 

Functional Testing Programming & Mapping Studies & Analysis, Imaging Hardware, Integration of 
BOSS into Single Hazardous Input Program ® 


PROJECT 95 DLA 016 
EXPORT TRANSPORTATION (EXTRA) 

Currently, business practices at the Defense Personnel Support Center (DPSC) related to the shipping 
tracking and .monitoring of troop issue and defense subsistence cargo movements are a largely manual 
processes which is tied to paper based and telephonic systems. This results in a clerical and 
administrative burden which is manpower intensive and limits the time available to perform more 
meaningful logistics management functions. v 

This project will develop a personal computer (PC) based system for the electronic processing of canm 
movement documents. The system will provide for enhanced shipment tracking as well as facilitating 
the timely requisition, procurement and transportation decisions in the DoD supply and transportation 
communities. As the distribution application determines how the requisition will be supplied Ti e 
through source load military distributor, depot, or Defense Subsistence Office (DSO) shipmentl,' the 
t A I RA system will determine initial cargo van requirements for advance bookings. 

When the contract award data on the material being shipped is available, final van requirements are 
determined by EXTRA and submitted directly to the overseas terminal operators. Capitalizing on 
commercial earner automation efforts, DPSC will maintain in transit visibility on DOD shipments 
Using o 1 a Status Detail transaction sets input either through EDI or other communications means, the 


4 of 9 


11/13/96 8:23 A 




.v u //oiunpuos/scrategy/app 


commercial earners will provide continuing status reports from the time of pick up to and including 
delivery at find destination, ^e^events mclude port of entry (POE) actual time of arrival (ATA)°and 
POE actual time of departure (ATD), EXTRA reports will be requested by and produced on Cathode 
Ray Terminals (CRT) on an as needed basis with the ability to print on demand as minimally necessary 
Real rime processing will be utilized for those reports generated on a daily basis; the option for real time 
or batch processing will be supported for major reports generated less frequently. 

PSA: Logistics 


Lead DoD EC/EDI PM: DLA, POC Anthony Travia 
(215) 737-2652 

Transaction Sets: 

214 Carrier message 

300 Reservation 
315 Status Report 

301 Confirmation 
856 Ship Notice 

858 Shipment Information 


Status: Prototype 


PROJECT 95DLA 020 
AUTOMATED BIDSETS INTERFACE 

, ca ? fi i2e RS? S 211 5 million j n savings through the deployment of the Automated 

S^^^e.Purpose of ABI is to facilitate the electronic dissemination of Engineering 
Data Lists (EDLs), Technical Data Packages (TDPs), drawings, and technical information in support of 
spares reprocurement solicitations. The ABI pulls data from the migratory systems Joint Engineering 
Data M^agement formation and Control System (JEDNUCS), Standard Procurement Svstem (SPS) 
and the Techmcal Information Storage and Control Application (TISCA,); and then electronically 
transmits the 841 (Specification/Technical Infonnation) Transaction Set under the 3050 conventions to 
me trading partner. ABI is a major step in the DoD mandated "Continuous Acquisition and Life Cvcle 
Support/Electronic Data Interchange" (CALS/EDI) initiatives. Standard EC/EDI transmissions to trading 
partners will reduce vendor conversion costs and shorten procurement lead-times. Another benefit to this 
automated process is the improved quality and reduction in errors. 

The ABI functionality was successfully tested during June 1995 in Columbus, Ohio at the Defense 

Supply Center :(DCSC). During the test the automated bidsheets interface pulled data from 
Jt 1 UCS, built the EDL, and electronically transmitted the data cut to a Value Added Network (VAN) 

ART* ,S°in^ an - < !f rn • CS ^vT aS u 1 n ed by success of test > and the potential of the 

ABI. The test went well. , said Elliot. The challenge now is to modify the business practices both in 

the government and private industry to take full advantage of this technology." Rear Admiral Elliot 

recognizes the munediate savings to the government through the utilization of the ABI and fullv 

^DGSC^cfmonYv A* t0 ^ ° LA C£nterS atDESC > Dayton, OH; DISC, Philadelphia PA; 

Under the close supervision of Mr. Phil Altman, Program Manager, HQ DLA, ABI will be deployed to 
the three DLA centers. Further dissemination of the ABI will be pursued under the new name of 
Dissemination of Digitized Drawings for Reprocurement (DDDR) with potential deployment DoD wide. 

^A^!| l !^^n^ l0 ^..^^!^A 0inI eff01 ? of the Federal Govmnttnt mi rivate industrv 

DLA and LOGICON (formally SYSCON) are coordinating this effort to bring this product to fruition. 
PSA: Logistics ' 
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Lead DoD EC/EDI PM: DLA, POC Philip Altman (703) 
767-2601 

Transaction Sets: 841 (3050) Specifications/Technical 
Information 

Status: Prototype to Demonstration in FY96 


PROJECT 95NAV 008 
NON-STANDARD DEMAND REPORTING 

Procuring activities report non-standard purchases to the Navy Inventory Control Point (NAVICP) for 
the Purposes of haying a National Stock Number (NSN) assigned to items purchased that had been 
identified by their local stock numbers (LSN). This NSN identification reduces the number of 
non-standard local procurements and provides the benefits of centralized management of material. 

Currently these reports are received in an 80 column format, as prescribed by 

Military Standard (MILSTD), with a document identifier code of "BHJ", (BHJ is a three digit document 
identifier code assigned to mtra-Navy transactions related to inventory control systems.) These 

fTr e cS? lder J t ify reports on the purchases of non-standard material (no NSN has been 
assigned). MILSTD s 80 column linutation inhibits the ability to accurately catalog the item for stock 
numbering because important data is often truncated (e.g., part number) or not transmitted due to the 
restriction of the Military Standard Transaction Reporting and Accounting Procedures (MILSTRAP) 
format. In addition reporting procedures are not standardized, and data is transmitted either nre- or 
post-award, depending upon the activity. Both pre- and post-award information is required as the 
P u S ' a M u P ? t > nu ^ ber ^ a y L be obsolete and a replacement part purchased instead. Both part numbers 
should be cataloged under the NSN for cross reference purposes. Additionally, the original quantitv from 
the requisitioner is required to ascertain the demand vice the amount actually purchased In many cases 
the customer may only need "one each" of an item but the vendors minimum order quantity is higher 
This results m excess inventory of these non-standard items with no visibility of these excess items to 
other Navy procuring sites because of the LSN which, under the current system, has no meaning bevond 
the local activity. This results in the different buying activities purchasing the same items with identical 
minimum quantity problems. 

In order to correct the existing situation the Navy's initiative will develop a new procedure which will 

Sf? , C u Urtent ,rSn m ^ d Procurement Accounting Data Entry (APADE) process and Electronic 
Data Interchange (EDI). Which, when implemented, will pull specific elements from the APADE 
System to assist the activity in the accurate and timely identification of these purchases. This data will 
be transmined directly to NAVICP in Mechamcsburg where it will compile product demand information 
which will then be utilized to improve the Navy's cataloging. 

The new format accommodates variable length data, and will be reported real-time on both requisitioner 
request and upon the award of a contract. Both pre and post- award data will be received. If the original 
requirement for an obsolete item results in procurement of its replacement, both part numbers will be 
cataloged under one NSN for cross reference purposes. If a local stock number is not reported, one will 

;^^ S Vfi e A^rV^^w 0n u Wl1 be USedt °P?P ula l e a non-standard database which will be distributed 
to the field by NAVICP Mechamcsburg. Visibility of excess assets, caused by the minimum order 
requirements, via the local stock number should eliminate some of the buv requirements The cross 
ref i re x C rc n x S r ° • obsolete/replacement pan numbers also eliminates the need for many LSN procurements 
as the NSN will be requisitioned instead. New NSNs will be assigned to those items that meet the 
criteria. 

Implementation of a standardized electronic, real-time reporting system will result in improved supply 
support. Inventory cost, labor and local procurement efforts will be reduced. Use of variable length 
records and an improved data transmission will facilitate NSN assignment, provide non-standard 
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material visibility, and improve inventory management practices. This program will automate demand 
processing and be expanded to accommodate specific service/DoD requirements and cataloging criteria. 

PSA Logistics 

Lead DoD EC/EDI PM: Navy, POC Diane Sechrist 
(717)790-2548, DSN 430-2548 

Transaction Set: 867 Product Transfer and Resale Report 

Status: Prototype 

DoD EC/EDI Funding: FY95 
S278K Mapping, Software, and Project 
Management Support 

FY96 

S249K Hardware and Project 
Management 


PROJECT 95NAV 010 

REQUISITIONING OF NON-STANDARD MATERIAL 

Prior to procurement of items of supply, they must be properly identified and described, either by the 
requisitioner when submitting the original request, or by other personnel in the supply system at some 

K cur ? me ^™ s 1S ? e Mt f chnica ! screening" process. For material formally identified by 
National Stock Number (NSN), technical screening is part of routine cataloging procedures. However 
over ^00,000 non-standard requisitions are submitted each year which have predominately required 
manual review for technical .screening. 4 

While many, of the Navy supply processes have been automated over the years, the non-standard 
requisitioning process remains bound in a manual, paper environment. During visits to ashore and afloat 
activities to ascertain their need for more expedient technical screening methods, it was discovered file 
drawers full of old paper messages, cumbersome technical manuals, drawings and microfiche were still 
being utilized. The Fleet and Industrial Supply Centers (FISCs), working as regional providers of 
services, as well as individual screeners were not able to share data; therefore creating redundancy Ion* 
lead times and unnecessary delays in the procurement of non-standard items. ’ 5 

As part of the FISC intenveaving initiative, a working group was established to examine further the 
feasibility of centralizing the function and identifying possible dollar savings without loss of service to 
the customer. Therefore, the Naval Supply Systems Command (NAVSUP), in its continuing efforts to 
reduce costs of operations through standardization, centralization, and downsizing, adopted a 
methodology to consolidate the requisitioning process at the Naval Inventory Control Point (NAVICP'l 
with a Host module residing at NAVICP Mechanicsburg, the Central Technical Activitv (CTA) a ' 
customer support module at each user activity and a storefront module at each FISC to manage ’ 
problem-case requisitions. * 

The Automated Non-Standard Requisitioning System (ANSRS) is an automated (paperless 
environment) program which performs a basic-level technical review (customer level) of each 

= enerates 311 electronic requisition, downloads requisition and forwards to the CTA/FISC 
s< V reens ^coming electronic requisitions through the CTA and generates status in 
the NAVICP Document Status File (DSF). Validations and edits are built into the svstem and 

a11 occurs via the Streamlined Alternative Logistics Transmission 

System (SALTS)/Electromc Data Interchange (EDI), and the Military Standard Transaction 
and Issue Proce dures (MILSTRIP) via Uniform Inventory Control Program 
(UICP)/Unlform Automated Data Processing System (UADPS)/Shipboard Uniform Automated Data 
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Processing System (SUADPS) transmissions, so as to maintain status and demand criteria. The svstem 
screens out exceptions and queues those items with inadequate data for manual review. As part of this 
process, ANSRS produces a database of all non-standard requisitions, resident, maintained and updated 
at the CTA. A tailored version will be distributed via CD-ROM as part of the customer and 
FISC/storefront modules. As records on new items are added to the CTA non-standard database 
providing historical data and past procurement history, the program will become more proficient at 
screening requisitions, expediting technical screening of subsequent requisitions for same or similar 
items. Sayings with respect to purchase of hazardous materials and storage of these materials will be 
realized smce each technical screener at the customer, FISC and CTA level will have access to technical 
information identifying these items and the methodology necessary to process them correctly. 

Implementing EDI within ANSRS will provide a standard format so that a system interface can be 
designed, pus will allow customers to provide more complete and accurate information and reduce lead 
times and delays. In addition, EDI will allow the flow of non-standard demand data from the 
procurement system to the NAVICP. 

ANSRS is well into the developmental stage with its prototype date (March 1996) on track The 
centralization of the non-standard requisitioning process at the CTA will create a central repository for 
data to allow collection of part-numbered information, visibility of all part-numbered buys and will 
facilitate faster and more efficient sendee to the customer. In the long-run, as ANSRS propagates and 
assimilates users, the cost of processing non-standard buys will decrease and will ultimately drive down 
the total weapon systems support costs. 

PSA: Logistics 

Lead DoD EC/EDI PM: Navy, POC CDR Tom Williams ' 

(703) 607-0926 

Transaction Set: 511 Requisition 
Status: Prototype 

i 

Project Management Support, Mapping and Software, Integration, Analvsis, Project Management and 
Deployment Plans * 


PROJECT 95NAV 012 
MATERIAL SAFETY DATA SHEETS 


The law requires that the manufacturer provide a material safety data sheet (MSDS) for any of their 

PA 0 ^ncN COntamms , hazardous chemicals - The Defense Federal Acquisition Regulations Supplement 
(Dr ARS) requires that the services obtain an MSDS with each procurement of hazardous material 
There are other DOD business rules that require the MSDSs to be submitted by the procurement officials 
to their service focal point. These focal points have industrial hygienists review the "paper" MSDSs 
This review consist of weeding out duplicates, quality control, and adding data such as logistics related 
information. The manufacturers MSDS are then rewritten to conform to the DOD format. When this 
conversion has been completed the information is placed on a floppv disk and mailed to DODs Material 
Safety Data Sheets Central Repository. These steps are labor intensive and cause delavs in getting the 
material safety data sheets to the users of the products 


The current practice is for the vendors and/or manufacturers to submit the safety data sheets by mail in 
the forma* : that they the vendor, are most familiar. The change in the simplified acquisition threshold 
trom 520,000 to S 100,000 has led to an increase in the use of individual purchases by the buvin<* 
activities. The net effect is an increase in the volume of individual material safety data sheets being 
received at the central control point. The current paper treadmill system is overburdened and °ettin<> 
increasingly slower in getting the MSDS to the users. ® * 
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With the continuing industry interest and participation in this effort it will result in the focal points beine 
able to receive electronically transmitted and structured MSDS. When fully implemented with a license^ 
plate, which is a Universal Product Code (UPC), to link the product to the MSDS, it will reduce the 
current processing costs by approximately 50 % and allow the industrial hygienist to focus more on their 

areas of expertise. Another benefit will be easier tracking of the movement of hazardous material within 
JJOJJ activities. 


PSA: Logistics/Environmental Security 


Lead DoD EC/EDI PM: Navy, POC George Ganak 
(703)607-0245 


Transaction Sets: 848 MSDS 
997 Acknowledgment 


Status: Prototype 

Initiated development of data model for MSDS exchange between DoD and contractors. MSDS EC 
Strategic Plan, (50 /o complete) Development of Trading Partner Toolkit, Complete Strategic Plan, 

Sgu^ftoMSDS^DI™ 7 ’ Air F ° rCe ^ ° SA SitC ^ a PP Iication of Standard Generalized Mark-Up 
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APPENDIX G - DOD AGENCIES 


1.0 DLA (POC DLA/MMPRS) = 

1.1 Background 

DLA maintains five (soon to be four) inventory control points which are responsible for purchasing 
supplymg and managing specific commodities. Each center has a requirement to exchange information 
internal to DOD and additionally to conduct business with commercial vendors and suppliers 

Prior to the development of the DOD EDI infrastructure, DLA used the capabilities and services of the 
Defense Automatic Addressing System Center (DAASC) to enable the implementation of EDI for the 
Agency. Exhibit G.l - DLA Architecture, provides a pictorial representation of the current architecture. 

DLA Architecture 


DCSC 


DSCC 

3*11*7 


DAASC 



DDN, 
DISK, etc. 
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Exhibit G. 1 - DLA Architecture ~ “ 

The Defense Automatic Addressing System Center (DAASC), which is located in Dayton, OH and 

Tracy, CA, currently supports the following major DLA EDI requirements: 

• Routing of Military Standard (MILS) formatted information among DOD entities. 

• Conversion of the MILS data to XI 2 transaction sets to conduct business with commercial 
industry. 

• Management of the trading partner database. 

• Access to approximately 20 plus commercial Value Added Networks (VANs) and Value Added 
Service (VAS) providers tor blanket and small business set aside purchasing 

• Setup and maintenance of Prime Vendor mailboxes. 0 

• Provide Continuity of Operations (COOP) through mutual backup. 

The majority of the materiel management, depot maintenance and distribution systems/applications are 
Defense Logistics Support Systems (DLSS). These formats are used not only to exchange information 


1 of 3 


1 1/13/96 8:24 / 








.tt JU...11U/ u , 


-uauipuos/scrategy/app 


ssis ^is&jLSSta other , 

outside of the DLSS/DAAS arena. F 6 several A12 programs bemg supported 
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1.2 Requirements 


Each of DLA’s organizations uses X12 to support the purchasing process* however nr a ;* • 

J ja“D»ia DLA*wiU migratelo the 
with the recently redefined DU structure DLA will best busine fspractices. Consistent 

through the DAASC. DLA has been and continues to work clo^v^^is^to 1 ^^^!^? 80 ?? 118 
(procurement) traffic to the NEPs/ECPNs DI A anrt me a „iii m uliA » migrate all public 
currently conned with n °"' D0D VANs 


SnvWngs U (ASC^ XI2 sem ; FOT DLA t0 P rovide technica J 

MB) must be supported by the D1SA EC and EDI mhiewe”' transactlons ( a PProaching 2 


1-3 Analysis and Considerations 


suppliers. These^on^c^l^i^gemen S ^ensme°a steadv flowof^ s and contractual relationships with 
prices. Often, EDI transaction exchanges are a^Lt beSt 

dictate business practices to all segments of the vendor commnnitv un, re ahzesthat DOD cannot 
choose to use industry accepted ICs in lieu of the DOD/Federal Tf\ n?? C< ? 1 I J rLrnodlty s P ecific vendors 
the non-standard ICs while Encouraging 

ii/:. l. a.i . • ~ - . . _ _ . 
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2.0 DeCA (POC DeCA) 

2.1 Background 

2.2 Requirements 
2.3-Analysis and Considerations 
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APPENDIX I - FEDERAL CIVILIAN AGENCIES 


1.0 FEDERAL PROCUREiMENT(POC DUSD(AR)) 

1.1 Background 


P e President's Management Council chartered the Federal Electronic Commerce Acquisition Team to 
develop the Federal electronic commerce architecture. The procurement community is implementing 
EDI using Streamlining Procurement Through Electronic Commerce as its blueprint. S 


One of the outcomes of the Federal Procurement Streamlining efforts was the establishment of the 
Federal Acquisition Network (FACNET). The FACNET is not, as is implied by its name a physical 
hardware network, but rather a set of parameters, built along functional lines, to be used by Go vernment 
and private users when implementing EDI. The FACNET is designed to- 




Inform the public about Federal contracting opportunities 

Outline the details of Government solicitations 

Permit electronic submission of bids and proposals 

Facilitate responses to questions about solicitations 

Enhance the quality of data available about the acquisition process 

Be accessible to anyone with access to a personal computer and a modem. 


1.2 Basic Requirements 


P e P £ C ^ men } community is currently implementing EDI primarily for Small Purchase Procurement 
(over S-,o00 and under $100,000) using the DII to provide the "single face to industry." Other 
procurement activities are sending XI 2 transmissions but those are not using the DOD EDI architecture 
for transaction set ^distnbution. The DII is available to and is being used by many federal agencies which 
have been certified by DOD to- use it. These activities support 98% of the small purchase procurements. 
In addition, they support large procurements and many of the small purchases which are awarded to 
large and small contractors. 


As commercial vendors are continuously being registered to do business with the federal government 
electronically, it is expected that the amount of test traffic will remain relatively constant and the amount 
of production traffic will continue to increase. 


The Electronic Commerce Acquisition Team (ECAT) recommended an acquisition architecture centered 
around a virtual network for delivering standardized transactions to facilities accessible to value-added 
networks (VANs) and other entities as well as for delivering transactions.Initiallv the Agencies will 
connect through the DOD Network Entry Points (NEPs) for access to the VANs' The ECAT has 
recommended that other Federally-owned NEPs be established so the Agencies will have a choice of 
connections into the Virtual Network. 


1.3 Analysis and Considerations 


The EC A PMO has agreed to use the NEP portion of the DOD EC and EDI Infrastructure for VAN 
connections. It has allowed agencies to establish their own EDI gateways and internal and external 
communications support. 


The ECA PMO has encouraged regular contact with the DISA Center for Standards Management 
Committee to resolve IC conflicts and to develop government-wide ICs. 


Some Agencies have implemented EDI differently from other Agencies. Even within the same A<rencv 
operating at different locations, EDI is implemented differently. Individual agencies are permitted to use 
multiple gateways, running on different hardware, software, and use different ICs to exchange the same 
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types of X 1 2 transactions. This has required the DOD EC and EDI Infrastructure to develop multiple 
ways to handle Federal sites. Federal sites must establish standard ways to provide site information in a 
timely fashion to the DOD, NEPs and certified VANs. Stove-pipe implementations are developed 
without a consolidated agency approach. F 
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APPENDIX W - DISA SUPPORT CAPABILITY 

(POC DISA - D7) 


1.0 DISA Support Capability 


ms appendix describes the methods that DISA uses to provide EC and EDI support to its customers 
the Defense conmnumty and the Federal civilian agency community. It is intended to be an evolving ’ 

becomes avaUa We" EDI Strategy document 311(1 wiU be updated periodically as new information 


Thus appendix provides the need for EC in DOD, including a brief history of the events leading to 
today s. programs It gives an overview of DISA's processes for gathering the requirements for customer 
support, and a high level view of the plan for maintaining and upgrading the DOD EC/EDI 
infrastructure. It also describes the environment to be used for developing new EC/EDI 
implementations, provides an overview of DISA's approach to EDI standards management and 
discusses how the Global Combat Support System (GCSS) fits into the EC and EDI picture. 

1.1 Electronic Commerce 


Recent experiences in the DOD (e.g.. Medical Logistics) have proved the effectiveness of EC to rapidly 
procure critical items, reduce costs, simplify business transactions, reduce paperwork decrease 
inventory, and increase transaction reliability. Despite its benefits, EC throughout theDOD is being 
implemented through a multitude of Service and Agency initiatives with disparate directions DOD 
components use a vanety of platforms, processors, networks, and transaction data standards to conduct 
tL. 1 he systems are stove-piped" and many use proprietary software and communications protocols 
T ° ?°r^ meSS eIec1 *onically, an industry trading partner has to meet a different set of requirements for 
each DOD activity. Current efforts to solve these problems have focused on small purchase 
procurement. The scope of EC must be expanded to include govemment-to-govemment traffic as well as 
fraffic between government and industry trading partners for Contract Administration, Transportation 
Supply Management, Financial Management, Maintenance, and Engineering 


EC/ED 1 has the potential for improving Federal Government operations, including our ability to sustain 
US forces, by streamlining procurement, logistics, personnel, medical, transportation, financial and 
reserve component functions. The GCSS EC/EDI product area provides common EC/EDI services and 
infrastructure so that DOD functionals, and functionals in other Federal Agencies, do not have to 
duplicate and pay for these capabilities individually. Common standards assure that EC/EDI applications 
used for combat support functions can interoperate with those used bv other Federal Agencies and our 
trading partners in industry. ® 


1.2 Electronic Commerce/Electronic Data Interchange 

b 

This section will begin with a brief summary of the background that led to the requirements for that 
portion of the DII needed to support the scope and objectives of EC/EDI. The next section will briefly 
- r ^-functional requirement process performed by DISA. It is followed by a focus on foe 
tu/EDI infrastructure upgrades and schedule. Discussions of foe standards program and GCSS will 
complete this appendix. 


1.3 Background 


On July 22, 1993, foe Deputy Under Secretary of Defense (Acquisition Reform) chartered a Process 
Action Team (PAT) to assess existing capabilities to conduct DOD contracting actions usm* EC The 
team found DOD components used a variety of platforms, processors, networks, and transaction data 
standards fo conduct EC; the various systems were often stove-piped and manv used proprietary 
software and communications protocols. To do business electronically, an industry trading partner (a 
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commercial entity desiring to do electronic commerce) had to meet a different set of requirements for 
each DOD activity. 

On December 20, 1993, the Secretary of Defense approved the PATs recommendation to initiate a 
24-month program to establish a DOD standard, centralized EC/EDI infrastructure. The Defense 
Information Systems Agency (DISA) was tasked to be the technical implementor of the PATs 
recommended architecture. 

Vice President Gores National Performance Review mandated the establishment of a Federal 
Government-wide EC program for federal acquisition below a specified dollar threshold In response to 
this policy statement, the Federal Electronic Commerce Process Action Team prescribed the use of 
DODs EC/EDI infrastructure for civilian Federal Government agencies. 

1995, the Assistant Secretary of Defense (Command, Control, Communications, and 
Intelligence) mandated that the EC/EDI infrastructure support electronic business in all functional areas 
At that time, DIS A was tasked to "establish an EDI infrastructure implementation advisory group 
consisting of Military Services, Defense Agencies, and other appropriate participants, representing as a 
minimum, the functional areas of Procurement, Health, Finance, Human Resources, Logistics 
Environmental Security, and Reserve Affairs." 

Clearly, the scope of the EC/EDI project must encompass transactions beyond small purchase 
procurement, mcluding govemment-to-govemment traffic as well as traffic between government and 
industry trading partners. To efficiently accommodate electronic business for the expanded scope of 
functions, the EC/EDI infrastructure will incorporate EC technologies beyond EDI. 

2,0 DISA Cross-Functional Requirements Gathering 

Exhibit W.l illustrates the elements involved in driving EC and EDI cross-functional infr astructure 
requirements. DOD and Federal functional customers are the prime generators of requirements. DISA is 
the implementor of the requirements. The requirements process and its supporting structure is the 
methodology by which user needs are integrated into DII programs. To facilitate this process DISA/D7 
has integration managers assigned to assist functional customers at the CINCs, Services OSD and 
Agencies. ’ 

The evolution of a requirement begins as depicted in Exhibit W.l. By looking at the total customer need 
the ability to leverage data gathering and provide a better integrated suite of products and services to the 
customer is improved. 
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Exhibit W. 1 - EC and ECI Requirements Drivers 


Requirements are analyzed continually for their insertion into the design and development process. 
Cross-functional requirements that can quickly lead to improved interoperability are given priority in the 

R en ect ed m the next section are the near term requirements that will lead to an enhanced 
hC/hDI infrastructure. 

3.0 Infrastructure Upgrades and Schedule 

Dining FY96, the focus will be on phased development of the ECPN operations consolidating the NEP 
and gateway functionality. Other activities will be integration and continued development of the 
Contractor Registration System, program translators and the phased elimination of the gateways and 
phased communication media transfer. Once all of the workload is transitioned to the new architecture 
future infrastructure upgrades will coincide with the identification and validation of the requirements in 
each of the new business areas projected to use the EC/EDI infrastructure. A list of past and future 
upgrades follows: . 

First Quarter FY96 
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Hardware delivery/configuration of new ECPN architecture at SlideU, Columbus and Ogden 
Establishment of engineering developmental site 

Network management, relational databases, automated auditing, rudimentary error processing 
Second Quarter FY96 

Formal Testing of ECPN software version 1.0 
Development of operational manuals/training materials 
Configuration management of operational infrastructure configuration 
Operator Training 

Provide hardware/software tools to CSC for on-line transaction status 

ECPN software installation 

User/operator acceptance testing of architecture 

FOC of ECPN software version 1.0 

Elimination of SAACONs/AF gateways, consolidation of functionality into ECPN 

Software development of enhanced error processing, integrated archival database/off-line transaction 
storage 

CCR initial-ECPN integration 

i 

Third Quarter FY96 
Elimination of remaining gateways 
Development of version 1.2 
CCR fully integrated into ECPN 
Automated workload allocation system 
Fourth Quarter FY96 through FY97 
Software enhancement for identified customer requirements 
Hardware capacity upgrades 
Mass data storage capability 

Transfer of new functional areas onto the infrastructure 
Version 2.0 of enhanced software 
FY98 

Capacity upgrades as required 
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Continued requirements validation of new functional areas 

Software development of ECPN functionality to meet additional requirements 


FY99-00 


Continued software development to meet changing/evolving customer requirements 
Exhibit W.2 below summarizes the EC/EDI Product Area Schedule. 


Electronic Ocmmerce Processing 
Nbdes (EC 3 Ns) 

Hardware deOvery/configiration 

(Slidell, Columbus, &Qgderfl 

ECPN Software Ver 1 .0 ' 

User/Operator Acceptar ce Testing 
Installation 

Train Operators — 

Binination of SAACONsfAF gateways 
ECPN Software Ip grades 

FY96J 

; FY97 f 

. FY98 ^ 

FYSQ^OI 


L.. A 

4 i 

i 


Var 1.2 
Ver 20 

Hardware Upgrades 



A 

k. 

Capacity 

Mass Data Storage 
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4.0 Development Environment 

i 

r^ni!iL?T d 7c l0p , men i enVlr °^ en ^ f0r new ° r ^sitioned EC and EDI projects will be the DISA 
Compliance Test Facility Electronic Commerce Processmg Node at Slidell, LA. DISA will provide the 

configuration control necessary to ensure that implementations under development will be isolated from 
the production environment and that they are created according to the agreed upon specifications. 
Special tracking and testing will be performed when developing cross-functional EC and EDI 
implementations. 

5.0 Standards 

“5 s ? 0D inf0 ™ M ;°P technology (IT) standards and conventions. 
i hin DISA, the Center for Standards, pan of the Joint Interoperability and Engineering Organization 

^ nomSvi^ 011 1 ? 12 ? 3 x!?" f ° r D ° D and . EDI standards and Implementation Conventions (ICs). 

The DOD EDI Standards Management Committee supports the development, adoption, publication and 
configuration management of EDI ICs for DOD. ^ ’ puuiu.duon, ana 

5.1 Standards Management 

Since the purpose of an EDI implementation is to exchange EDI information among disparate 

S meS J Stines strict conformance to broadly agreed information technology standards is 
par mount. Although manv Military Services and Defense Agencies use standards to conduct business 
industry, coordination of standards usage throughout the Department of Defense remains a 
critical need, hor the most pan, American businesses use. or plan to use, the American National 
Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 standards for exchanging data 

sSffitoTriS U* (DStoT“ (EDI> - D0D 15 comraitted ,0 ,he un iform use of standard? and Draft 
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When implementing EDI, many factors must be considered, including: the Federal. Information 
Processing Standards (FIPS), the X12 Standards process, the migration of X12 to EDIFACT and the 
role ot a single set of Federal Implementation Conventions (ICs). 

5.2 Implementation Conventions 

EDI Syntax standards, both X12 and EDIFACT, are intended to accommodate a full range of business 
activities for all industries. They are developed by consensus among a large number of users each with 
his/her own set of needs. The resulting standard is very broad and is intended to meet the diverse 
requirements of all users. The DISA Center for Standards provides the management structure and 
mechanisms necessary to coordinate functional and technical efforts to tailor existing standards into 
documented DOD Implementation Conventions for use within a particular operational environment 
Business functionality is the preeminent requirement of EDI IT Standards and functional (business area') 
participation in the standards process is required for the successful application of DOD EC and EDI 

StE? nSf r SA f T y JP on f or fractional participation through PSA working groups that cooperate 
with the DISA Center for Standards m the standards process. v 

53 Federal Information Processing Standard (FIPS) 161-2 (Draft). 

FIPS PI m np a p°p?m S??7 dance Wi * ? 0S V rf ?P' ed by the Federal Government via 

FIPS PUB 161-2 (Draft). FIPS PUB 161-2 does not mandate the implementation of EDI systems within 

the Federal Government; it requires the adoption of two families of information syntax standards The 
two syntax standards are the X12 for domestic information exchanges and United Nations Electronic 
Data Interchange For Administration, Commerce and Transport (EDIFACT) for international 
information exchanges. 

5.4 ANSI Accredited Standards Committee X12 

Although a number of industry specific syntax standards for the electronic exchange of business 
information exist, X12, accredited by ANSI, is generally recognized as the North American EDI 
standard and is well supported in a number of Pacific Rim nations. Most industry specific standards have 
committed toaligning themselves with X12. Federal Agencies which were using industry specific 
standards on jO I September 1991 may continue to do so for five years from that date. Industry specific 
standards may be used beyond five years only if no equivalent X12 (or EDIFACT) standard is approved 
by jO September 1 996. X12 consists of a number of underlying standards and addresses a wide ran <*e of 
busmess requirements. Since most EDI information exchanges are domestic and X12 is more mature 
than EDIFACT, X12 is the primary EDI syntax for the DOD. Management of X12 is accomplished 
through a number of functionally oriented sub-committees. A close working relationship between 
individual DOD members and these sub-committees has evolved and it is in the DOD's best interest to 
maintain these relationships. DOD participation in X12 sub-committees generally comes from a wide 
range of functional users. . J 

a PP r °y e a P^ ^°J lec ^ ca ^ migration to and administrative alignment with 
UN/EDIFACT. New efforts are underway to merge the X12 standards into those of EDIFACT The two 
‘ c “ x ‘ a .” * e D0D this transition. The DOD, through X12, is participating in the 
development of EDIFACT message which will be required to trade with international partners. 

6.0 GCSS 

The Global Combat Support System (GCSS) initiative deals with providing a common infrastructure for 
co-existence and interoperation of automated information systems, or functional applications providing 
combat support This environment is also to be interoperable with the Global Command and Control ° 
bystem (GCCS). The functional applications are being developed by various central design activities 
belonging to the Services and Agencies, on behalf of the Principal Staff Assistants having oversight of 

, pn T' WOrk ,°I GCSS 00nsists “f preparing common components of 

the infrastructure and helping the central design activities interface the functional applications to that 
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infrastructure. 

The first of the five GCSS product areas, Functional Applications, deals with defining what is required 
~. e an application to GCSS and with any modification(s) required to the application itself. 
Modifications to applications that are necessary to operate on a common infr astructure to include 
common services, shared data, communications, and common hardware platforms fall ’under this product 

arS ?*J5f i egr !f of f nodlficatloIls required wiU vary by application and will be defined and scheduled to 
match the functional requirements for fielding the applications. 

pe other four product areas deal with providing for or modifying the common infrastructure so the 
functional application can operate with it. The EC/EDI product area provides common services and 
infrastructure for this service area so that each functional area does not have to repeatedly develop and 
pay for these capabilities. As long as each application provides data in a commonly defined fashion it is 
assured logical as well as physical interface with other Government applications and with EC/EDI 
trading partners m Industry. The Common Operating Environment (COE) product area is an area that 
complements modifications done to the application. While the application may be modified to run on the 
COE, it is possible the COE may lack some services required by multiple applications. Modifications on 
the application will be done under the Functional Applications product area while modifications to the 
COE would be done under the COE product area. 

Similarly, the shared data environment product area will provide the services and infrastructure 
necessary to facilitate and achieve shared data for each functional application. Any modifications needed 
?° r ^application are done under the Functional Applications product area, but as more applications are 
integrated into GCSS, it is expected that modification and expansion of the underlying shared data 
environment will be necessary, Finally, EC/EDI, COE and a Shared Data Environment all need a 
communications mid hardware infrastructure which will be provided by the Communications and 
Computing Shared Infrastructure product area. This will provide an integration and testing facility for 
GCSS, communications upgrades to support GCSS traffic, and fund common hardware a£d software 
infrastructure necessary to facilitate the fielding of GCSS. Several methods will be used for this latter 
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APPENDIX X -ISSUES / ACTIONS 

(POCDISA-D7) 


This appendix documents the issues that have been identified during development of this strateev and 
recommends the action(s) that should be taken to resolve the issues. The issues are presented in table 
format on the following pages. F m ldDie 


The following table is a list of issues or requirements and one or more related actions to be taken The 
meaning of each table column is: 1 ne 

Org The organization about which the issue is concerned. 

Issue The issue, stated as a problem or as a requirement. 

Action A specific and measurable action designed to resolve the issue. 

Action Org The organization(s) responsible for the action. 

Compl Date The expected completion date for the action. 

Action Type (P)olicy, (O)perations, (OBE) Overcome By Events, or something else 
Time F rame Near, Mid, or Long Term do we need this now - with date? ° 


Org 

Issue 

Action 

Action Org 

DFAS 

1. DFAS HQ has agreed to 
implement EDI for unmatched 
disbursements using the DOD 
EC and EDI Infrastructure. 

1 .a Monitor progress of the 
implementation. 



2. DISA must ensure the 
ECPN architecture is prepared 
to handle 

govemment-to-govemment 
exchange of transactions, and 
is able to replicate and 
correctly address one 
transaction to multiple 
locations. Until the ECPN is 
deployed, the current DISA 
gateways must accommodate 
DFAS' requirements. 

2.a Develop routing tables to 
accommodate the requirement 
of one transaction to multiple 
locations. 



3. There is a requirement for 
govemment-to-govemment 
exchange of EDI 850s 
(contracts) and 860s (contract 
modifications) in XI 2 version 
3050 for major weapon system 
procurement The 
requirements must be collected 
with enough lead time to 
complete DOD EC and EDI 
Infrastructure enhancements 
well before DFAS milestones. 

3. a Develop the functional 
requirements for 850s and 
860s. 

DISA D7 
DFAS 
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4. There is a requirement to 
develop functional 
requirements for the capability 
to send single transactions to 
multiple locations. The 
requirements must be collected 
with enough lead time to 
complete DOD EC and EDI 
Infrastructure enhancements 
well before DFAS milestones. 

4.a Develop the functional 
requirements for one to many 
transaction distribution. 

DISA D7 
DFAS 


5. There is a requirement to 
develop functional 
requirements for the capability 
to pay the vendor and send the 
XI 2 820 Remittance Advice to 
the Department of the 
Treasury. The requirements 
must be collected with enough 
lead time to complete DOD 
EC and EDI Infrastructure 
enhancements well before 
DFAS milestones. 

5. a Develop the functional 
requirements for vendor pay 
and Remittance Advice. 

DISA D7 
DFAS 

USTRANSCOM 

6. There is a need for an 
analysis of DISN connections 
for all Defense transportation 
activities, and to provide ways 
to connect to DISN if activities 
are not connected. 

6.a Perform an analysis of 
DISN connections. 

DISA 

USTRANSCOM 



6.b Provide DISN connections 
for activities that need it. 

DISA 

USTRANSCOM 


7. There is a need to conduct a 
transportation-specific ECPN 
performance/throughput/speed 
of service test and to develop 
requirements to begin the 
transition of EDI traffic from 
its commercial VAN 
connections to the 
Infrastructure's VAN 
connections. 

7.a Conduct ECPN 
performance tests. 

DISA 

USTRANSCOM 



7.b Develop requirements for 
transition to infrastructure 
VAN connections 

DISA USTRANSC 

i 

8. There is a need to gather 
transportation industry 
encryption and 
non-repudiation security 
requirements and to 
incorporate Global 
Transportation Network 
(GTN) services and support 
into the GCSS. 

8. a Gather security 
requirements 

DISA GCSS PMO 
USTRANSCOM 
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8.b Incorporate GTN services 
and support into the GCSS. 

DISA GCSS PMO 
USTRANSCOM 


9. There is a need to 
incorporate transportation 
industry-specific data 
requirements into the Federal 
X12 ICs 

9.a Update the Federal X12 
ICs transportation 
requirements. 

USTRANSCOM DI 
Center for Standards 

Medical 

Logistics 

10. There is a need for Medical 
Logistics to begin using the 
DOD EC and EDI 
Infrastructure. 

10.a Collect Medical Logistics 
functional requirements. 

DISA 

Medical Logistics 



1 0.b Perform testing of 
performance/throughput/speed 

of service. 

_ 

DISA 

Medical Logistics 



lO.c Develop Medical 
Logistics EDI deployment 
plan. 




lO.d Medical Logistics begin 
sending EDI traffic to the 
Infrastructure 

DISA 

Medical Logistics 


11. There is a need to 
incorporate Medical Logistics 
specific data requirements into 
the Federal X12 ICs 

1 l.a Update the Federal X12 
IC Medical Logistics 
requirements. 

Medical Logistics D 
Center for Standards 

DLA 

12. There is a need for DLA to 
begin using the DOD EC and 
EDI Infrastructure. 

12.a Collect DLA functional 
requirements. 

DISA 

DLA 

V 


12.b Perform testing of 
performance/throughput/speed 
of service. 

DISA 

DLA 



12.c Develop DLA EDI 
deployment plan. 

DISA 

DLA 



12.d Identify and certify VANs 
that DLA needs to use in the 
EDI infrastructure. 

DISA 



1 2.e DLA begin sending EDI 
traffic to the Infrastructure 

DISA 

DLA 


13. There is a need to 
incorporate DLA specific data 
requirements into the Federal 
X12 ICs 

13. a Update the Federal X12 
IC DLA requirements. 

DLA 

DISA Center for 
Standards 


14. There is a need to 
transition DLA trading partner 
direct connections to the EC 
and EDI Infrastructure. 

14.a Analyze DAASC value 
added services and 
functionality to determine how 
they can be added to the DOD 
EC and EDI Infrastructure. 

DISA 
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15. There is a need for DLA to 
use X12 version 3050 
transactions in the EDI 
Infrastructure. 

15. a Analyze methods to 
transition DLA translation 
sites to the ECPN gateways. 

DISA 


- 

15.b Prepare the DOD EC and 
EDI Infrastructure for DLA 
conversion to XI 2 version 
3050. 

DISA 

ECA PMO 

16. There is a need to write a 
Federal- wide EC and EDI 
strategic plan, help agencies 
present a unified requirement 
to ensure solutions are not 
stove-piped and that the 
solutions adhere to the Federal 
EC and EDI strategic plan. 

The ECA PMO needs to 
provide technical and 
functional POCs for each 
agency to coordinate all 
agency EDI implementations. 

16.a Write a Federal- wide EC 
and EDI strategic plan. 

DISA D7 can assist 
ECA PMO 



16.b Assist agencies to present 
a unified requirement that 
adheres to the Federal EC and 
EDI strategic plan. 

DISA 



16.c Provide a technical and 
functional POC for each 
agency to coordinate all 
agency EDI implementations 

ECA PMO 


17. There is a need to establish 
requirements for NEP access 
to the central Federal database, 
incorporate Federal NEPs into 
the DOD EC and EDI 
Infrastructure, and implement 
cross-functional EDI projects. 

17.a Establish requirements for 
NEP access to the central 
Federal database 

DISA D7 
ECA PMO 



1 7.b Incorporate Federal NEPs 
into the DOD EC and EDI 
Infrastructure 

DISA D7 
ECA PMO 



1 7.c Implement 
cross-functional EDI projects. 

DISA D7 
ECA PMO 


1 8. There is a need to enhance 
ECPN functionality to meet 
requirements identified to 
DISA D7 and implement 
standard solutions in 
accordance with the ECA 
PMO strategic plans. 

1 8. a Enhance ECPN 
functionality to meet 
requirements 

DISA 



1 8.b Implement standard 
solutions in accordance with 
its strategic plans. 

ECA PMO 
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There is a need to transition 
stovepiped EDI solutions to 
the standard solution; 

19.a Identify stovepiped EDI 
solutions that need to be 
moved to the new 
infrastructure. 

DiSA 
ECA PMO 



19.b Develop and execute a 
plan for the transitions. 

DISA 

ECA PMO ’ 

DISA 

Central Contractor 
Registration 

3/15-01: Corinne Engle will 
update the matrix to include 
the August 94 requirements as 
a requirements source and 
update any issues and actions 
as a result of this meeting. 




3/15-02: D6/EDS will provide 
Char Ivey an impact analysis 
(cost and schedule impacts) on 
processing multiple PLA loops 
in one 838 per day to D&B, 
and include the CCR ID and 
password in the request. 




3/15-03: Judy Monje/D&B 
will provide an 
analysis/proposal from D&B 
of what turn-around time can 
be expected under the current 
way CCR is doing business, 
i.e., one TP for each 838. 


i 

- 


3/15-04: A meeting with CCR 
and CTF needs to be held to 
define/refine the boundaries of 
responsibilities between CCR 
and CTF, including who will 
be responsible for notifying 
the TP of his confirmation. 




3/15-05: An MO A should 
establish and MOA with CTF 
that specifies the criteria for 
turn around times for CTF 
validation. This should include 
the terms for both before and 
after automation. 




3/15-06: D6/EDS will develop 
a proposal on how to send the 
notification of CTF validation. 




3/15-07: D6/DUSD(AR/EC) to 
get a "strawman" Errata 
3/IC3060 to CCR workgroup 
so functional community can 
have input. 
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3/15-08: D3/D6/Gateway 
Administrators should 
establish a process to 
communicate with the gateway 
administrators. 




3/15-09: The functional user oi 
the data (DLSC?) should 
prepare instructions for the 
gateway administrator and 
AISs on how to use the data. 




3/15-10: Mike Smith to 
provide Charlene Ivey 2 cost 
estimates: 1) the spend plan 
and requirement for additional 
funds to continue the support 
to the PC program beyond the 
90 day time frame; and 2) a 
cost estimate for the 
development, redistribution 
and documentation for Errata 2 
of the PC program. 


_ 


3/15-11: DISA (D6&D7) to 
provide to Charlene Ivey the 
status of SOW deliverables, 
the dollars expended to date on 
each CCR SOW and the plan 
of action to continue CCR 
development and funding. 

\ 

\ 


3/15-12: D6/EDS to provide j 
Charlene Ivey a cost and 
schedule estimate for the 
development of an on-line 
environment to support 50 
concurrent users. It was later 
agreed that this estimate would 
include alternative 
technologies such as using the 
World Wide Web. This " 
proposal will also include the 
proposed screen designs. 




3/15-13: Charlene Ivey to 
provide Mike Smith with 
guidance on proceeding with 
the PC Program. 


. 

] 

3/15-14: CTF (Lib Curtis) to 
test the PC program for Errata 
2 when it becomes available 
from Mike Smith. 
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3/15-15: EDS/D6 will provide 
handouts of the on-line 
registration screens to Mike 
Smith so he can get them to 
the CCR AWG members prior 
to the next meeting. These 
should be emailed to Mike 
Smith by 20 March. 




3/15-16: Deborah Germak will 
provide electronic copies of 
the PC software screens to all 
members of the CCR AWG 
via email. 




3/15-17: D6/EDS to provide 
Charlene Ivey a cost and 
schedule estimate for 
developing the SIC 
requirement. 




3/15-18: Judy Monje to 
provide 3 copies of the SIC+2 
diskette to DISA-D6 (Mike 
Riha). 




3/15-19: Mike Riha and 
Deborah Germak will jointly 
develop a SOW for follow-on 
CCR development and present 
it to Charlene Ivey. 


I 


3/15-20: D6 will develop 
technical alternatives to 
invalid DUNS that are 
validated by D&B and present 
them to Char Ivey for a 
decision. 




3/15-21: D6/EDS/Charlene 
Ivey will sit down and discuss 
D6's proposed predefined 
queries that are based on FOIA 
data. The proposal will be part 
of the 29 March proposal from 
D6. 




3/15-22: Jim Gordy will 
consolidate the results of the 
Dec 5-6 and 20 CCR splinter 
group technical requirements 
and the geographic query 
requirements and the results of 
any other previous meetings, 
and any required DISA input 
into answers for the 5 page 
questionnaire. 
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3/15-23: DUSD(AR/EC) will 
raise the issue of data access 
and usage to Mr. Kelman’s 
task force. 




3/15-24: D6/EDS to propose a 
solution that includes the 
DUNS and a password to 
verify a TP's 

access/modification request on 
his CCR profile. This proposal 
shall also include any request 
for support to process the 
mailingof passwords to TPs. 




3/15-25: Charlene Ivey will 
propose words for the VLA 
that VANs must release the 
TPINs to the TPs and that the 
TP IN is the property of the TP. 
Also note that confidentiality 
of the TPIN must be assured. 




3/15-26: Charlene Ivey will set 
up a meeting between the 
DUSD(AR/EC) office and the 
federal ECA PMO to discuss 
details about federal 
organizations registering in 
CCR and the D6/EDS proposal 
for subphase 2. 




3/15-27: LESCO will send 
EDS a government registration 
for testing. 




3/15-28: The D6/EDS v 
proposal will include short 
range COOP/BEP solutions. 



- 

3/15-29: D7 will research the 
21st century date codes in 
CCR for clarification of the 
problem. 




3/15-30: DUSD(ARZEC) will 
get authorization for the Navy 
to modify AISs for joint TP 
profile downloading 
capabilities for reporting 
purposes. 

* 

Army 


1) Action Item: Research 
waiver to FAR clauses that 
impact FACNET. 

ODUSD(AR/EC) 



2) Action Item: Provide Lt 
Col Walsh with an electronic 
copy of the ECIC Strategy 
Plan. 

ODUSD(AR/EC) 
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3) Action Item:. Follow-up on 
the Bell Atlantic D.O. 
implementation 

ODUSD(AR/EC)/D 



4) Action Item: Follow-up on 
equipment storage that is being 
used in Bosnia effort. 

ODUSD(ARZEC) 



5) Action Item: Provide 
follow-up information on CCR 
effort. 

D2/D7 

Navy 


6) Action Item: Provide Navy 
the information promised at 
the DISA 12/95 functional 
users meeting. 

D2/D7 



7) Action Item: Conduct 
conference call to understand 
the services requirement on 
ECPN implementation issues 
and the impact to the 3050 and 
2003. 

D7 



8) Action Item: Manually 
scanning of error files to find 
transactions is a problem. 
Explore the possibility of 
automating a red flag" of error 
files. 

D3 

i 


9) Action Item: Communicate 
an understanding of ECPN to 
the services (customers) or 
continuous customer 
education. 

DISA 



10) Action Item: CCR 
Interface operations manual 
will DISA prepare this? If so. 
then the Navy wishes to be 
involved in this process. 

DISA 



11) Action Item: Can the 
trading partner profile 
information be downloaded 
from the CCR in the ECPN 
environment in the future and 
in the present architecture? 

DISA 



12) Action Item: What is level 
of testing is currently being 
tested on the VANs and VAS 
(end to end testing)? 

DISA 



13) Action Item: Provide the 
Mr Nielsen a copy of the 
software system used to son 
Trouble Tickets?(DISA) 

D3 

i 
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14) Action Item: Is there a 
way for a customer to check 
the status of Trouble Tickets? 

D3 



15) Action Item: DISA and 
Navy put together a 
implementation plan for Kings 
Bay, GA. Navy provide DISA 
their definition for flawless 
implementation. 

NAVY AND DISA 

* 


16) Action Item: Establish 
policy issue on the VANs don't 
keep the original RFQ record 
and don't know what 
transactions sets have been 
sent or to whom received 
them. This issue is regarding 
amendments to solicitations 
and whether they should be 
canceled and a new solicitation 
issued each time there is a 
change to the solicitation since 
many VANs/VASs do not 
offer the service of tracking 
RFQ numbers. Provide regular 
updates to Navy and 
components. This is important 
to the AIS users. 

ODUSD(AR/EC) 

l 


17) Action Item: How can we 
educate vendors on which 
convention to learn (3050 or 
2003)? DISA Provide 
guidance. 

DISA 



18) Action Item: Provide 
procedures or software that 
will enable the Navy ECIC 
representatives to DECODE 
DISA word processing 
attachments from their E-mail. 

DISA 



19) Action Item: Will DISA 
or the services test 
requirements on 3050 with 
trading partners? 

DISA 



20) Action Item: Is the ECPN 
dates given (February 15, 
1996) still valid? 

DISA 



21) Action Item: DISA set-up 
teleconference with customers 
on the 3050 and 2003 testing. 

DISA 



22) Action Item: Navy wants 
more information on the query 
capability that the ECPN 
implementation can provide. 

DISA 
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23) Action Item: Establish 
policy issues on VANs 
unilaterally removing clauses 
that pertain to an RFQ. 

ODUSD(AR/EC) 


- 

24) Action Item: Trading 
Partner Profile functionality 
currently at the Gateway part 
of ECPN functionality? 

DISA 



25) Action Item Navy 
requested information about 
the 838 status, including 
ERRATA 2. 

DISA 

Air Force 
! 


1 . Arrange for a separate 
meeting with AF to discuss 
and resolve transition of the 
Wright Patterson AFB 
workload onto the ECPN 
without AF Gateway support 
or decide that AF must add an 
additional Gateway to support 
the volume of workload. 

DISA 

1 


2. Provide follow-up 
information on CCR effort. 

DISA 

| 


3. Arrange a separate meeting 
with component 
representatives on CCR status. 

ODUSD(AR/EC) 



Table of Contents 


DISA D7 Home Pace 


DISA Home Pase 


II of 11 


1 1/13/96 8:33 A 



APPENDIX Y -REFERENCES 

(POC DISA - D7) 


This appendix lists various documents, working erouDs and action teamc that ^ u • . 

m the Federal government's efforts to identify mdS mv ? Ived 

Electronic Commerce. Each item contains a synopsis of the effort and of . 

access to it Reader, of this document are encoded » co kSbute“o tte cZSli™ ga “ 
mputs to Mr. Jim Mulder at the address given in the forw“dVo SS docker.” V ^ 


ITEM/ SYNOPSIS 
LOCATION 


a C0 ? m ? n °OD |C vision by defining requirements, roles and responsibilities and 
for J ciuevm S a rifled approach to EC implementation and operation. In addition it serves 
to document the current and future capabilities of the Defense Information Systems Aoencv mr? Z 

^vnfv; 11 mcreasi n8 fip workload through the Defense Information Infrastructure (DID. It is an 
evolving document that is intended to be updated periodically to identify c han ges in remiin»mf»ntc a a 
the strategies that need to be tailored to fulfill those requirements ** § requirements and 


“S UeC, ' 0niC ^ (EDI > Tn “J Bus^ess Relate, 

Not available until finalized 

executi^d^^ 

InTr^iSed" ^ C,r0mC Va,a ‘"“•'change ImpUmemanon Plan, November 19! 

Prescribes an aggressive plan to accelerate the pace of EDI implementation in suoDort of 

aimed a - foc , usmg ener sy> attention and resources toward ex P Mdin°EDI uses in 
support of D°D transportation business information exchanges. It identifies basic requirement? for the 
use of EDI m support of POD jmnsponation iu addition to detailing g^EDnSves 


F ederal Acquisition Streamlining Act of 1994 

SBA On-line BBS 1-800-697-4636 as "Small Business Guide to Procurement Streamlining 

Workf Wide (REF ° R>, TXT) “ fl,e ~ 

acquisitions, promote electronic commerce, und improve fa efficiency of“Smem 

T/ * - - 1 


Tour Introduction To Electronic Commerce -A Handbook lor Business 

fhttTu mC Comme ? e In/ormation Center 1-800-EDI-3414 or Internet World Wide Web 
(http://wvvw.acq. osd.mil/ec/subjects.html) 0 

so ftwar ^ re q u^r e rn ' COmmumcal,ons ’ con tractor registration, standards, andhardware and 
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Federal Electronic Commerce Acquisition Instructions (FECAI) — 

SB A On-line BBS 1-800-697-4636, or Internet World Wide Web 
(http://www.acq.osd.mil/ec/ecic_hpg.htmI 

These instructions explain how contractors register with the Federal government They describe the 

nSw° Tt°,in Sm8 e m f te I re § lstr a tI0n J^base to avoid repetitive registrations with each procurement 
aIso c ° v ^ standards, value added service providers, electronic payments and financial 

electronic commerce with the Federal government. 

F ederal Implementation Convention Guidelines 
1-800-334-3414 

Electronic Commerce/Electronic Data Interchange is conducted using national or international 
standards. As a matter of common practice, standards are seldom used in their entirety An 
Implementation Convention is a subset of a standard that conforms to the standard but onlv 
implements that portion of the standard that is applicable to the using organization' The Federal 

C J °r nt J 10n J Guidelines are based on the American National Standards Institute 
(ANSI) Accredited Standards Committee (ASC) X 1 2. 

Defense Management Reports Decision (DMRD) 94 1 , 1 990 
Unknown 

Stated that the strategic goal of DOD’s current efforts is to provide the department with the capability 
to initiate, conduct, and maintain its external business related transactions and internal logistics 
contracting, and financial activities without requiring the use of hard copy media 

Defense Information Infrastructure (DII) Master Plan ~ ~ 

(703) 607-6342 (DSN 327-), POC lLt Vincent Williams 

The DII Master Plan reflects DOD Components’ collective strategy for providing the Warfighter with 
formation capabilities to achieve mission success. The key purposes of the DII Mater plan are to- 
establish the common DOD vision of the DII to ensure unity of efforts in its achievement; identify 
current and future elements of the DII; define roles, responsibilities and relationships for all of DOD’s 

P 1 n£S2nfS ; - : T fy ^ rel ?^ sl i ps 1111(1 interdependencies of current DII initiatives; and assist 
in planning and implementing of DII efforts across DOD. 

\ Defense Information Systems Agency Home Page ' =j 

Internet World Wide Web (http://www.itsi.disa.mil/ 

h °™ ?/ P t a / §e ftS!I ta i? S a . var ?- et ? of information including a listing of compliance tested software 
packages (/ct/soft/html) and a listing of compliance tested VASs (/ct/vas.html). 
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APPENDIX Z - GLOSSARY 


TERM 

| DEFINITION 

AIS 

Automated Information System 

ANSI 

American National Standards Institute 

ARCC 

Acquisition Reform Communications Center 

AR/EC 

Acquisition Reform/Electronic Commerce 

ASC 

Accredited Standards Committee 

ASD(C3I) 

Assistant Secretary of Defense (C3I) 

C2 

Command and Control 

C3I 

Command, Control, Communications and Intelligence 

CCR 

Central Contractor Registration 

CDA 

Central Design Activity 

CFS 

Center For Standards 

CFSE 

Center for Systems Engineering 

CISS 

Center for Inlormation Systems Security 

COE 

Common Operating Environment 

COOP 

Continuity of Operations 

COTS ~] 

Commercial-Off-The-Shelf 

CSC 

Customer Service Center 

CTF 

Compliance Test Facility 

DBOF 

Defense Business Operations Fund 

DCTF 

DISA COOP and Test Facility 

DFAS 

Defense Finance and Accounting Service 

DU 

Defense Information Infrastructure 

DISA 

Detense Information Systems Agency 

DISN 

Defense Information Systems Network 

DLA 

Defense Logistics Agency 

DMC 

Defense MegaCenter 

DMLSS 

Defense Medical Logistics Standard Support 

DMS 

Defense Message System 

DOD 

Department of Defense 

DPCSC 

Defense Procurement Corporate Information Management Systems Center 

DUSD( AR/EC) 

Director for Electronic Commerce 

DUSD(AR) 

Deputy Under Secretary of Defense (Acquisition Reform) ~ 1 

ec r 

Electronic Commerce 

ECIC ! 

Electronic Commerce Information Center 1 

ECIC ] 

Electronic Commerce in Contracting 
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ECPN 

(Electronic Commerce Processing Node ■ . '] 

EDI 

Electronic Data Interchange 

EDIFACT 

EDI for Administration, Commerce and Transport 

EDISMC 

EDI Standards Management Committed 

EFT 

klectronic Funds Transfer 

FACNET 

tederal Acquisition Network 

FECAI 

federal Electronic Commerce Acquisition Instructions 

FRD 

functional Requirements Document 

FTP 

Pile Transfer Protocol 

GCCS 

Global Command and Control System 

GCSS 

Global Combat Support System 

GOTS 

Govemment-Off-The-Shelf 

GW 

Gateway . 

IC 

[Implementation Convention 

IOC 

Initial Operational Capability 

IPT 

Integrated Process Team 

IT 

Information Technology 

JIEO 

Joint Interoperability Engineering Office 

JITC 

Joint Interoperability Test Command 

JLSC 

Joint Logistics Support Center 

MHSS 

Military Health Services System 

iVIILS 

Military Standard 

MLFPIP 

Medical Logistical Process Improvement Program 

NEP 

Network Entry Point 

NIPRNET 

Non-classified Internet Protocol Router Network 

OSF 

Operational Support Facility 

PAT | 

Process Action Team 

PSA 

Principal Staff Assistant 

SMC 

Standards Management Committee 

SPS 

Standard Procurement System 

TDCC 

Transportation Data Coordinating Committee 

TP ‘ 

Trading Parmer 

URL 1 

Uniform Resource Locater 

USD(A&T) p 

Under Secretary of Defense (Acquisition & Technology) 

USTCJ4-LT p 

US TRANSCOM J4-LT | 

VAN p 

Value Added Network 

WWW p 

^Vorld Wide Web 
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